These are chat archives for orbitjs/orbit.js

9th
Jan 2016
Oliver Searle-Barnes
@opsb
Jan 09 2016 00:55
Back to how to represent reductions, here’s how rethinkdb handles it:
full-records
full_records.png
reduced-records
reduced_records.png
so they always just use an array
and show a partial representation of a record for reductions
Oliver Searle-Barnes
@opsb
Jan 09 2016 01:03
(just food for thought, not suggesting we follow that approach)
Dan Gebhardt
@dgeb
Jan 09 2016 04:01
I guess it's obvious, but the results just come down to the implementations of the reducing expressions
I can see the benefit of reducing expressions that maintain record identity in the result set
as well as expressions which "anonymize" the results (e.g. just return an array of attribute values)
we should probably be constrained in the number of expressions we support at first
and consider new additions as needed
Dan Gebhardt
@dgeb
Jan 09 2016 04:07

I think the key simplifications we're discussing are that:

1) unordered sets should be simple POJOs so that patch operations work upon them

2) ordered sets can be arrays, which patch operations also work upon

3) sets that maintain record identity can be simple POJOs keyed by id

Oliver Searle-Barnes
@opsb
Jan 09 2016 05:15
@dgeb perhaps we should introduce store.queryRecords or similar, which knows to use the identity map (whether it be via wrapping the query in a toRecords operator or just hard coding the Identity map lookup in queryRecords). Querying for records seems like the typical scenario so it makes sense to have a shortcut for it which just wraps a call to 'query'.
and definitely agree we should keep the standard operators to a minimum
Abdulhaq Emhemmed
@abdulhaq-e
Jan 09 2016 22:40
Hello everyone, thanks for this awesome library, @opsb and @dgeb ; you guys are doing an amazing job. I have a question, well more than one question. 1- There isn't a method for obtaining compound documents from a JSON API source, is that correct? I looked everywhere for an "include" query parameter and didn't find anything.
2- Some tests for the JSON API source are commented out, are these affected by the current "work in progress" issues? If not, I will be happy to refactor them to the new Query interface.
3- RxJs has been included in the library, are there (future) plans to replace promises with observables everywhere?
Oliver Searle-Barnes
@opsb
Jan 09 2016 23:02
Hey @abdulhaq-e I don’t use the JSON API source myself, I’ll have to let @dgeb chime in there. WRT to RxJs, the plan is to continue to use promises for source.query() (which only return a single value) and to use observables for source.liveQuery() (which returns a stream of updates).
Dan Gebhardt
@dgeb
Jan 09 2016 23:14
@opsb I agree with your queryRecords proposal - it seems natural to keep that in the EO.Store and simply lookup the results in the identity map before returning them
and of course we could also have liveQueryRecords
I think these methods will feel more natural than forcing the use of a toRecords expression
Oliver Searle-Barnes
@opsb
Jan 09 2016 23:16
yeah, that’s my feeling as well
Dan Gebhardt
@dgeb
Jan 09 2016 23:16
ok cool
Oliver Searle-Barnes
@opsb
Jan 09 2016 23:16
registering extra operators seems an unncessary step at the moment
Dan Gebhardt
@dgeb
Jan 09 2016 23:16
yeah
Oliver Searle-Barnes
@opsb
Jan 09 2016 23:17
after @abdulhaq-e’s question I’m curious what your plan is for the JSON API source, will you implement what is becoming the standard set of OQL operators?
Dan Gebhardt
@dgeb
Jan 09 2016 23:18
I need to circle back on that source definitely
I would like to support as much as possible
obviously some combinations won't be possible - or will require extra processing once results get into orbit
Oliver Searle-Barnes
@opsb
Jan 09 2016 23:19
yeah, joins with criteria would need multiple requests
Dan Gebhardt
@dgeb
Jan 09 2016 23:20
right
Dan Gebhardt
@dgeb
Jan 09 2016 23:25
@opsb just reviewing your ember-orbit PR
"I think the only thing left to get this green is a release of the current version of orbit.js#rethink."
Oliver Searle-Barnes
@opsb
Jan 09 2016 23:26
right
Dan Gebhardt
@dgeb
Jan 09 2016 23:26
so we are pointing bower directly at the orbit repo now
and you're pulling from the rethink branch
Oliver Searle-Barnes
@opsb
Jan 09 2016 23:27
yeah, that obviously doesn’t work :) locally I’m just symlinking
ah, sorry, I have a modified bower.json locally
Dan Gebhardt
@dgeb
Jan 09 2016 23:28
are you locally symlinking to orbit's build dir?
Oliver Searle-Barnes
@opsb
Jan 09 2016 23:28
yeah
we need to release that somewhere so that ember-bower can depend on it
Dan Gebhardt
@dgeb
Jan 09 2016 23:29
we can auto-push to orbit-builds canary branch
Oliver Searle-Barnes
@opsb
Jan 09 2016 23:30
yeah, that would probably do it
Dan Gebhardt
@dgeb
Jan 09 2016 23:30
longer term we need to consider just using the ES6 modules directly from lib
Oliver Searle-Barnes
@opsb
Jan 09 2016 23:30
don’t really need all the versions, just the latest
yeah, I did see something in ember-data earlier that was related to that
I’ll see if I can find the PR
Dan Gebhardt
@dgeb
Jan 09 2016 23:30
ember-data is "doing it right" now
Oliver Searle-Barnes
@opsb
Jan 09 2016 23:30
right
Dan Gebhardt
@dgeb
Jan 09 2016 23:31
they are maintaining a -private dir
Oliver Searle-Barnes
@opsb
Jan 09 2016 23:31
yeah, I saw that
Dan Gebhardt
@dgeb
Jan 09 2016 23:31
for non-public modules
we should follow suit
ember will be doing the same soon
Oliver Searle-Barnes
@opsb
Jan 09 2016 23:31
although doesn’t the ember-addons addon directory achieve the same thing?
as opposed to app
Dan Gebhardt
@dgeb
Jan 09 2016 23:32
sort of
Oliver Searle-Barnes
@opsb
Jan 09 2016 23:32
WRT to loading ES6 modules directly, I think we want to add both the ember-orbit and orbit.js source trees into the ember app’s broccoli pipeline
Dan Gebhardt
@dgeb
Jan 09 2016 23:32
you can still access my-addon/some-module from your app
so it's namespaced
Oliver Searle-Barnes
@opsb
Jan 09 2016 23:33
ah, I see
ok, -private makes sense then
Dan Gebhardt
@dgeb
Jan 09 2016 23:33
yeah -privateis a nice hint
Oliver Searle-Barnes
@opsb
Jan 09 2016 23:33
ha, subtle
Dan Gebhardt
@dgeb
Jan 09 2016 23:33
lol

WRT to loading ES6 modules directly, I think we want to add both the ember-orbit and orbit.js source trees into the ember app’s broccoli pipeline

:+1:

Oliver Searle-Barnes
@opsb
Jan 09 2016 23:34
I did see a PR for ember-data this morning which mentioned the hook that’s used to achieve that, can’t find it now...
here it is emberjs/data#4048
Dan Gebhardt
@dgeb
Jan 09 2016 23:36
nice
Oliver Searle-Barnes
@opsb
Jan 09 2016 23:36
so it looks like we’d add the ember-orbit and orbit.js trees into https://github.com/pangratz/data/blob/a11303dac652a40bb0f2750de7e90d5c2751f939/index.js#L46
seems straightforward enough
and not having to publish separate builds would be very nice
Dan Gebhardt
@dgeb
Jan 09 2016 23:37
yeah it feels so broken
Oliver Searle-Barnes
@opsb
Jan 09 2016 23:37
although I imagine we’ll do that anyway for other builds
Dan Gebhardt
@dgeb
Jan 09 2016 23:37
I suppose we should continue
Oliver Searle-Barnes
@opsb
Jan 09 2016 23:38
I think a release per tag would make the most sense for other builds
auto-release via travis that is
Dan Gebhardt
@dgeb
Jan 09 2016 23:39
I agree
might as well auto-release to the canary branch as well
Oliver Searle-Barnes
@opsb
Jan 09 2016 23:40
true
Dan Gebhardt
@dgeb
Jan 09 2016 23:40
we should cover all the possible clients that way
and most importantly have it automated
Oliver Searle-Barnes
@opsb
Jan 09 2016 23:40
yeah, for sure
I’m pretty much done with updating orbit-rethinkdb for OQL, only slight snag is that there’s no changefeeds on joins yet(pegged for rethinkdb 2.5). Currently trying to figure out how to fake a join...
I’ll try and get store.queryRecords done today
Still aiming for an end to end demo by the end of the weekend, this join issue may block that though