New data not directly available

[janober]

You mentioned in #5 that there is a delay because of the N1QL indexing. So that new data will not be available directly. Is there a way around that? For example not using N1QL when I already have the document id? (no idea if that is even possible, do not know enough about Couchbase and the plugin yet)

The reason is that I will have muliple processes which access the same data and add to an array. If the delay is a few milli-seconds it should not be a problem. However after testing simply with the loopback-explorer it looks to me that the delay is more in the few second range which will definetly be a problem here and in very many other cases.

Do you use the plugin in production and if so was that never a problem?

[nolandubeau]

This is a N1QL indexing issue. We're hoping that this get's faster as N1QL
comes out of developer pre-release. The way to get around it is to just
use the native couchbase node module and do a get on the document key. it
should be available right away. I know it's a pain, but I had to do this
recently myself as I couldn't wait for N1QL to index.

On Tue, Jan 27, 2015 at 8:34 PM, Jan [email protected] wrote:

You mentioned in #5
#5 that
there is a delay because of the N1QL indexing. So that new data will not be
available directly. Is there a way around that? For example not using N1QL
when I already have the document id? (no idea if that is even possible, do
not know enough about Couchbase and the plugin yet)

The reason is that I will have muliple processes which access the same
data and add to an array. If the delay is a few milli-seconds it should not
be a problem. However after testing simply with the loopback-explorer it
looks to me that the delay is more in the few second range which will
definetly be a problem here and in very many other cases.

Do you use the plugin in production and if so was that never a problem?

—
Reply to this email directly or view it on GitHub
#7.

_Nolan Dubeau_VP, Engineering, Guardly Corp.
Online: https://www.guardly.com
LinkedIn: http://www.linkedin.com/in/nolandubeau
20 Maud Street, Suite 307, Toronto, ON M5V 2M5
CA (416) 434-8029 | US (650) 262-3599 | Skype: nolandubeau
Please consider the environment before printing this email.

[janober]

Thanks for the fast answer!

I wonder if it then would be worth directly including the native couchbase node module in this plugin and always use it when the Id is available. This would then speed it up and would also make sure that if the work around is not needed anymore it would just have to get changed at one place (this plugin) instead of all the applications which use it.

I do not know much about N1QL (honestly nothing, did not look into it at all). But if I understand it correctly it will always need to index first which means it will probably never be as fast as when querying directly. That makes me believe that this work-around is something permanent and nothing temporary which would be another reason including it here would make sense.

[nolandubeau]

Thats a great suggestion Jan. I will run it by our dev team. I think this
would work in many cases but not all.

N1QL is like SQL for couchbase. Before N1QL you had to create Couchbase
Views in order to "query" data. If you're just querying for an ID (or
document key) then yes adding the native couchbase.get would probably work
in this case. But as soon as you add filtering or includes via loopback
then this is where N1QL shines since you can start doing stuff like JOINS
across docTypes.

Check out the tutorial here which will help you to get a better grasp -
http://query.pub.couchbase.com/tutorial/#1

On Tue, Jan 27, 2015 at 9:13 PM, Jan [email protected] wrote:

Thanks for the fast answer!

I wonder if it then would be worth directly including the native couchbase
node module in this plugin and always use it when the Id is available. This
would then speed it up and would also make sure that if the work around is
not needed anymore it would just have to get changed at one place (this
plugin) instead of all the applications which use it.

I do not know much about N1QL (honestly nothing, did not look into it at
all). But if I understand it correctly it will always need to index first
which means it will probably never be as fast as when querying directly.
That makes me believe that this work-around is something permanent and
nothing temporary which would be another reason including it here would
make sense.

—
Reply to this email directly or view it on GitHub
#7 (comment)
.

_Nolan Dubeau_VP, Engineering, Guardly Corp.
Online: https://www.guardly.com
LinkedIn: http://www.linkedin.com/in/nolandubeau
20 Maud Street, Suite 307, Toronto, ON M5V 2M5
CA (416) 434-8029 | US (650) 262-3599 | Skype: nolandubeau
Please consider the environment before printing this email.

[janober]

Thanks for the explanation!

Then I understood it more or less right. Yes I mean really just in the case when querying for an id and nothing else. In lookback that would be the "findById" (maybe even "find/findOne" where the where-clause just contains an id but I guess that is not so important). Another advantage next to having the data instantly would probably be a little performance improvement. I guess going through N1QL for a simple query like that produces at least some kind of overhead that can so be avoided (no idea if it would be worth for that reason alone though).

[janober]

After having looked through the code I saw that more or less almost everything was already there but not used. The "find" method does exactly that but it seems loopback never calls that. Instead it always calls the "all" even if I do an "findById" which seems very very strange but ok. So I changed the code in my repro to use that method whenever an "id" is given in the "where". If you and your dev-team approve that it makes sense here is the code:
janober@4e65c86

Again can not open a pull request because of the still open other one. But is simply enough anyway.