Open ierceg opened 10 years ago
That's weird. Of course this is not how adapter should work. All what adapter should do is to translate query from jugglingdb abstraction to database abstraction. Adapter should not implement what already implemented in database. If you know how to deal with nano - feel free to amend implementation.
And jugglingdb's abstraction is to implement findOne
in terms of adapter.all
plus filtering, right?
I'll see what I can do.
Yep. .findOne is like .all just with {limit: 1}, and .find is for lookup by id.
On Thu, Jan 16, 2014 at 11:04 AM, Ivan Erceg notifications@github.comwrote:
And jugglingdb's abstraction is to implement findOne in terms of adapter.all plus filtering, right?
I'll see what I can do.
— Reply to this email directly or view it on GitHubhttps://github.com/jugglingdb/nano-adapter/issues/11#issuecomment-32459673 .
Thanks, Anatoliy Chakkaev
+1
You will encounter performance issues with the current .all implementation.
I'm having some issues with jugglingdb or the nano adapter inserting bogus data after retrieval so during the debugging I had to go through the implementation of
all
in the adapter. I was surprised that it pulls all the records onto the client and then filters them essentially using the database backend as a simple storage not as a proper database. I'm intending to fix this, if I can, but I was just wondering if this was some deliberate design choice or just an oversight?