4.0.0-beta.6
Pre-releaseThis release drafts the sixth beta version of QDB4.
Yet another beta release of the QDB module. I've implemented and improved a lot of things since the last version. As predicted in the previous beta version, there have been major changes in terms of efficiency and structural formatting of the database.
Fixes
- Prevent DataStore property being stored. (7c489f9)
- Fix cached object model having an incorrect cast. (add1408)
Selection
Secondly, Selections have gotten a fairly big usage improvement since the previous prerelease of QDB. There are a lot of new methods and performance improvements included in this version, such as:
<Selection>.Group(Key: String) -> Selection
- Based on a SQL GROUP BY statement.
- Groups this Selection into categories specified by the value of the
Key
attribute per each entry.
<Selection>.Map(Fn<Val, Key, i>: Function) -> Selection
- Identical to
Array.prototype.map
. - Maps each entry with the value returned from the callback function.
- Identical to
<Selection>.Clone(Holds?: String) -> Selection
- Creates an identical, deep copy of this Selection instance.
<Selection>.Join(Secondary: Selection, Field: String, Property?: Boolean|String) -> Selection
- Based on a SQL FULL JOIN statement.
- Groups entries in a dictionary named after
Property
that have matching keys as specified by theField
parameter. - The
Property
parameter can either be a direct name, a booleantrue
to use the Selection's hold property, orfalse
to flatten the values into the Selection's entry.
<Selection>.Merge(...Selections: Selection) -> Selection
- Inserts the entries of the secondary Selections into this Selection instance.
Database Iteration
As for the Each()
, Find()
and Select()
methods, I have implemented a few changes that improve the performance of those instructions by a fair bit. These improvements are achieved by fetching the entire database instead of rows one-by-one, which I should've done in the first place. For the find function, there's now an optimisation where it iterates through the cache before touching the database itself, which results in partial faster retrieval of the outcome.
Internal Thread Deprecation
Lastly, I decided to deprecate the implementation of internal Pool threads. I'm convinced that it would be far more useful if you created your own implementation of multiple threads or processes. It would be far more performant, together with the fact that it's far more controllable than an internal solution.