Major Update - LokiJS 2.x.x #525
Comments
|
Here are some thoughts from me:
That is all from me, what do you think? =) |
|
@Viatorus Some time ago I began working on bringing the changes from master into the 2.0 branch but due to a lack of time I did not finish it.
For now I think I'll try to finally complete the master -> 2.0 merge within the next few days. That should make it easier to move forwards with the 2.0 release. |
|
Hey guys, this sounds in line with my objectives for winding 1.4x branch down to a maintenance support. Since the last merge I have overhauled the serialization subsystem but I would imagine the new LokiMemoryAdapter and LokiPartitioningAdapter would just need their interface to be 'promis-ified'. If this proves too much work, perhaps you can just temporarily disable the TravisCI (if needed) and I will attempt to update any issues based on work already done by @Cortys. I also updated a lot of unit tests to increase code coverage which can be commented out if they need refactoring. I was made aware of another minor functional gap which I could see being a final (minor) addition to close out non-maintenance additions. We keep binary indices generated by sorting on a property but we don't allow simple sorted retrieval which can leverage that index. That should be simple and I hope to just add that tonight or tomorrow at latest. Not sure sure the best way to 'support' 1.4 branch after we move to 2.0.0 active branch... perhaps we should elevate 2.0.0 to its own GitHub project and just duplicate crititcal fixes on that project. |
|
hey guys - yes LokiJS 2.x should really be its own repository. I believe
@obsliskos and I are on the same wavelength which is that we think of the
current implementation of LokiJS as "final", which means focus is on
maintainance, bug fixes etc. LokiJS 2.x can leverage all the lessons learnt
and a great deal of the concepts explored, but I would write Loki's code in
a radically different way nowadays.
…On Mon, Jan 9, 2017 at 12:53 PM, obeliskos ***@***.***> wrote:
Hey guys, this sounds in line with my objectives for winding 1.4x branch
down to a maintenance support. Since the last merge I have overhauled the
serialization subsystem but I would imagine the new LokiMemoryAdapter and
LokiPartitioningAdapter would just need their interface to be
'promis-ified'. If this proves too much work, perhaps you can just
temporarily disable the TravisCI (if needed) and I will attempt to update
any issues based on work already done by @Cortys
<https://github.com/Cortys>. I also updated a lot of unit tests to
increase code coverage which can be commented out if they need refactoring.
I was made aware of another minor functional gap which I could see being a
final (minor) addition to close out non-maintenance additions. We keep
binary indices generated by sorting on a property but we don't allow simple
sorted retrieval which can leverage that index. That should be simple and I
hope to just add that tonight or tomorrow at latest.
Not sure sure the best way to 'support' 1.4 branch after we move to 2.0.0
active branch... perhaps we should elevate 2.0.0 to its own GitHub project
and just duplicate crititcal fixes on that project.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#525 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AD8FfQqImCmfrt7iHZWMQrzLiGKU2Jkiks5rQi3VgaJpZM4LdwoS>
.
|
|
Thank you for your input. To summarize:
What should we do different/better LokiJS2? I updated the main post accordingly. |
…nce method ( #525 #524 ) before this commit, coll.chain().simplesort('username').data() would not use binary index to speed up results.... it will now (with no filters). resultset (chain) now contains an 'instance' method which will create an anonymous collection populated with objects in the current resultset... those docs were stripped of $loki and meta properties so those will be reassigned by new collection. Can pass collection options object to instance(). Terminates chain by returning anonymous collection (not linked to database). updated jsdoc and rebuilt minified
|
Ok, I think that will do it for feature additions to 1.4.x branch. Suppose we could allow pull requests on 1.4 if end users wish to extend its lifespan but those don't need to be brought over to 2.x... and we can just duplicate bug fixes. New 2.x repo sounds great. I will let you guys decide how radically you want to take LokiJS2... and how you wish to verify performance during architecture changes... perhaps our benchmarks should be upgraded as well. |
|
As discussed I just merged master #528. |
|
@Viatorus @Cortys @obeliskos @VladimirTechMan @alexandernst you're all invited to join LokiJS-Forge. I made LokiJS2 a repo under that organization, it seems fairer than for it to be under my personal account, given that my contribution to LokiJS is - and will be for the foreseeable future - quite limited (regrettably, time is really not on my side). We can start design and implementation discussion over at https://github.com/LokiJS-Forge/LokiJS2 PS. did i forget anybody? |
|
Thank you. This is a good idea. |
|
@techfort - maybe first make an initial commit to master with just a .gitignore and Readme. |
|
Hi there. Is LokiJS 2.0 available yet? Wondering if there is any good in-memory full-text search engine I can use for a production web site. I have less than 1,000 products to index so it's a pretty small DB. |
|
Hello, please have a look at: But it is still in development. |
Hey everyone,
I want to move forward with you to a new major release of LokiJS.
Let us discuss what our goal for 2.x.x should be and how we reach it.
Goals for LokiJS 2.x.x:
Procedure:
The text was updated successfully, but these errors were encountered: