These are chat archives for orbitjs/orbit.js

2nd
Oct 2015
Oliver Searle-Barnes
@opsb
Oct 02 2015 19:39
@dgeb I’m thinking about what to look at tomorrow, how far along do you think you’ll be?
Dan Gebhardt
@dgeb
Oct 02 2015 19:43
@opsb hey!
just getting back to orbit for the day
Oliver Searle-Barnes
@opsb
Oct 02 2015 19:45
just checking it out
Dan Gebhardt
@dgeb
Oct 02 2015 19:46
also haven't heard from @gnarf in a while ... Corey - please let us know what you think about Queryable, query expressions, etc. when you get a chance :)
Oliver Searle-Barnes
@opsb
Oct 02 2015 19:47
I’ve had a few thoughts about querying, haven’t put the pieces together uet but here it is so far.
One of the things I’ve been thinking about a lot is the form of the results for a liveQuery
I suppose I’ve been influenced by GraphQL a lot here, I’m wondering if the results object should actually be a tree of results.
Dan Gebhardt
@dgeb
Oct 02 2015 19:50
hmmm ... don't the results almost have to be in the normalized form?
Oliver Searle-Barnes
@opsb
Oct 02 2015 19:51
The results at each node in the tree would essentially be “records"
But they’d be read only
The result nodes would sit between the UI and the orbit store so it’s possible to denormalize
The result nodes would keep themselves updated as results streamed into the store, and it would also be possible to update the criteria for that node (for pagination etc.).
In terms of how this would work with ember’s templates, the model hook would return the root result and the components would traverse this to get to different result nodes.
I’m imagining this as a read only abstraction, modifications would be made directly against a transaction.
Dan Gebhardt
@dgeb
Oct 02 2015 19:55
so this skips over the concept of an identity map in the ember-orbit store, doesn't it?
your components are directly bound to the results instead
Oliver Searle-Barnes
@opsb
Oct 02 2015 19:56
yes
so I suppose it’s an alternative to ember-orbit really
Dan Gebhardt
@dgeb
Oct 02 2015 19:56
I see
Oliver Searle-Barnes
@opsb
Oct 02 2015 19:57
I’ve been thinking about how you might make it easy to bind inputs to a transaction as well
A bit like binding to a record directly, but it woud be a write only object.
Dan Gebhardt
@dgeb
Oct 02 2015 19:58
so you're proposing eliminating models entirely from the ember layer?
Oliver Searle-Barnes
@opsb
Oct 02 2015 19:58
That’s what I’m thinking about
Dan Gebhardt
@dgeb
Oct 02 2015 19:58
I see
Oliver Searle-Barnes
@opsb
Oct 02 2015 19:58
I’ve still got a fair amount of thinking today, but that’s the idea I’m pursuing
(remember I have a day job, haven’t had too much time to go through this yet ;) )
Dan Gebhardt
@dgeb
Oct 02 2015 19:58
sure :)
well, it's quite a radical proposal
Oliver Searle-Barnes
@opsb
Oct 02 2015 19:59
it’s obviously heavily inspired by relay and GraphQL
Dan Gebhardt
@dgeb
Oct 02 2015 19:59
sure
Oliver Searle-Barnes
@opsb
Oct 02 2015 19:59
having looked at those the do seem like a really good fit for what we do in our app
Dan Gebhardt
@dgeb
Oct 02 2015 20:00
doesn't this skip over the cache's normalized format expectations and everything?
Oliver Searle-Barnes
@opsb
Oct 02 2015 20:00
everything is realtime, and the issue we had before was not being able to control the denormalisation into the view (i.e. pagination on includes)
I think the normalized format is still useful, you need to be able to integrate changes when offline for example
This would be a denormalization layer that sat on top of it
The other thing I’ve been thinking about is when you have long lived queries it makes sense to start thinking about queries which know about all of the sources that are involved.
Dan Gebhardt
@dgeb
Oct 02 2015 20:03
hold on ... still stuck on denormalization :P
so you're getting back a denormalized format from GraphQL, sending it to the UI denormalized, and then somehow normalizing it for the cache?
Oliver Searle-Barnes
@opsb
Oct 02 2015 20:03
Yes, I have to admit that’s the bit where I start wondering if this is just crazy ;)
I have given some consideration to getting rid of the normalized format completely
Dan Gebhardt
@dgeb
Oct 02 2015 20:04
yeah, at that point it might make sense to just use flux / react directly
Oliver Searle-Barnes
@opsb
Oct 02 2015 20:04
But I’m not sure you’d integrate changes
Dan Gebhardt
@dgeb
Oct 02 2015 20:04
I hate to say that - but it might make sense for you
Oliver Searle-Barnes
@opsb
Oct 02 2015 20:04
Yeah, that is something that I’ve been considering as well
Unfortunately, it doesn’t have all the answers yet
There’s no realtime story for instance
It’s been mentioned, but I haven’t seen much activity around it
So yeah, tough position at the moment
Dan Gebhardt
@dgeb
Oct 02 2015 20:05
for real time updates to be distributed to multiple result sets, you'd need some kind of normalized understanding of the data in those result sets
Oliver Searle-Barnes
@opsb
Oct 02 2015 20:06
yeah
I have been thinking about writing an orbit-rethindb source instead of going the GraphQL route
Potentially it could do a good job of aggregating queries to rethinkdb
I could get to realtime much faster that way
at least with a naive implementation anyway
So yeah, I’ve got a good idea of what I need, just not sure the fastest way to get there
Dan Gebhardt
@dgeb
Oct 02 2015 20:09
ok fair enough
if you want real time updates to propagate to result sets, and you want to work offline, then you need to normalize your data
Oliver Searle-Barnes
@opsb
Oct 02 2015 20:09
yeah, that’s what I kept coming back to
Dan Gebhardt
@dgeb
Oct 02 2015 20:09
otherwise it's just "dumb data"
Oliver Searle-Barnes
@opsb
Oct 02 2015 20:10
yeah
Dan Gebhardt
@dgeb
Oct 02 2015 20:10
which might be all that facebook needs
Oliver Searle-Barnes
@opsb
Oct 02 2015 20:10
yes, that’s also true
Dan Gebhardt
@dgeb
Oct 02 2015 20:10
but it doesn't make sense for many "apps"
Oliver Searle-Barnes
@opsb
Oct 02 2015 20:10
yeah, I’d be curious to know if there’s any normalization that happens internally
Dan Gebhardt
@dgeb
Oct 02 2015 20:11
yeah, unsure what they're doing internally
Oliver Searle-Barnes
@opsb
Oct 02 2015 20:11
I think it’s fair to say it’s a constraint anyway
Dan Gebhardt
@dgeb
Oct 02 2015 20:11
normalization?
Oliver Searle-Barnes
@opsb
Oct 02 2015 20:11
yes
Dan Gebhardt
@dgeb
Oct 02 2015 20:12
agreed
Oliver Searle-Barnes
@opsb
Oct 02 2015 20:12
and if I’m using rethinkdb there’s no reason for me to denormalize when querying the server
possibly it’s simpler though
Could just do a dumb translation of the query from the UI into a changefeed on rethinkdb
I think the trick is in aggregating queries
Dan Gebhardt
@dgeb
Oct 02 2015 20:16
I suppose that we could allow select and merge expressions to merge results into a single set
and in that way queries could be joined
not sure :/
Oliver Searle-Barnes
@opsb
Oct 02 2015 20:17
yeah, I think it could be done with a query api
some kind of query calculus :)
Dan Gebhardt
@dgeb
Oct 02 2015 20:17
yeah
basically, query expressions could do anything to transform results
but the more complicated, the fewer sources will understand them
so we need to be careful
Oliver Searle-Barnes
@opsb
Oct 02 2015 20:18
if we used a lispy style, where all the expressions are of the form [op, arg1, arg2…] then merging could be relatively straight forward
Dan Gebhardt
@dgeb
Oct 02 2015 20:18
right
just wondering if we would expect individual sources to handle a merge expression for instance
Oliver Searle-Barnes
@opsb
Oct 02 2015 20:20
yeah, I’m not sure where that should happen
it couldn’t be done statically, I don’t think
Having said that, if expressions could be solved independently then they could be dependent on parent expressions
Dan Gebhardt
@dgeb
Oct 02 2015 20:24
not sure
I feel like we're solving a problem that's still 2 steps down the road
Oliver Searle-Barnes
@opsb
Oct 02 2015 20:24
yeah, it is the problem I need to solve though
just trying to figure out the rough form so that I know what steps are required to get there
don’t want to back myself into a corner
Dan Gebhardt
@dgeb
Oct 02 2015 20:25
fair enough
so the problem you're trying to solve here is that you want each component to be associated with a query that determines its needs, and then you want to be able to aggregate those queries as much as possible
Oliver Searle-Barnes
@opsb
Oct 02 2015 20:27
yeah, although I think aggregating the queries could be solved later
Dan Gebhardt
@dgeb
Oct 02 2015 20:27
yeah, the aggregation strikes me as an optimization that may be difficult to generalize
Oliver Searle-Barnes
@opsb
Oct 02 2015 20:28
true
well, I think it should be generalizable
you want to end up with a single query per table essentially
from the remote source anyway
Dan Gebhardt
@dgeb
Oct 02 2015 20:28
depends on the remote source I think
Oliver Searle-Barnes
@opsb
Oct 02 2015 20:28
it’s a different story against the memory source
sure
So, maybe that’s just a source’s concern then
Dan Gebhardt
@dgeb
Oct 02 2015 20:30
yeah
Oliver Searle-Barnes
@opsb
Oct 02 2015 20:30
As long as you can run the same query against the memory source then synchronisation between the sources can be normalized
So, it seems like the place to start would be a spike to try building the denormalization layer between the orbit store and ember
There’s good separation there, it would just require implementing the queries against the memory source, the remote source can come later
Dan Gebhardt
@dgeb
Oct 02 2015 20:34
so you're discussing expressions that denormalize the data (which may come from the memory source) for easy consumption by components, skipping models entirely?
Oliver Searle-Barnes
@opsb
Oct 02 2015 20:34
yeah
there’s definitely some details that need sorting out
that’s why I want to do a spike, see how it hangs together
Dan Gebhardt
@dgeb
Oct 02 2015 20:35
well, it certainly would be possible with the queries / expressions returning json instead of forcing normalization
ok
Oliver Searle-Barnes
@opsb
Oct 02 2015 20:36
yeah
Dan Gebhardt
@dgeb
Oct 02 2015 20:37
it's intriguing certainly - seems like a great fit for react tbh
Oliver Searle-Barnes
@opsb
Oct 02 2015 20:37
the idea definitely has appeal, the view layer is inherently denormalized, rather than get a normalized view of the data and wrangling it in the ember components, this would allow you to specify exactly what you need
yeah, I need to look at how well the approach will work with ember’s model
I suppose the denormalized layer will need to be ember objects
That way it will fit in with the component lifecycle
Dan Gebhardt
@dgeb
Oct 02 2015 20:39
well, you lose out on a lot of model-specific calculations and formatting via CPs by eliminating the Model per record approach
Oliver Searle-Barnes
@opsb
Oct 02 2015 20:40
true
Dan Gebhardt
@dgeb
Oct 02 2015 20:40
and I'm unclear about the approach to creations / deletions / updates
probably has to be entirely functional
Oliver Searle-Barnes
@opsb
Oct 02 2015 20:40
My intention was to simply use the transaction api, addRecord, updateRecord etc.
Dan Gebhardt
@dgeb
Oct 02 2015 20:40
right
well, it could work - will be an interesting experiment
Oliver Searle-Barnes
@opsb
Oct 02 2015 20:41
yeah, it’ll be interesting for sure
Dan Gebhardt
@dgeb
Oct 02 2015 20:41
:)
Oliver Searle-Barnes
@opsb
Oct 02 2015 20:41
will probably give me a deeper understanding of the differences between the ember and react models :)
Dan Gebhardt
@dgeb
Oct 02 2015 20:42
no doubt!
?
do you agree that we need a synchronous query method to replace retrieve?
Oliver Searle-Barnes
@opsb
Oct 02 2015 20:43
hmm
would make sense with the store
Dan Gebhardt
@dgeb
Oct 02 2015 20:43
yeah, pretty much only for memory sources
would make livequeries more responsive
Oliver Searle-Barnes
@opsb
Oct 02 2015 20:44
yeah, for sure
the question is, when is a liveQuery “ready”?
the rescue behaviour with liveQueries isn’t so clear
how do you decide whether or not the memory source has enough information to return
i.e. sometimes you want to do a rescue (the first call) after that an assist probably
ah no, different semantics
so when you call the same liveQuery the second time you would want the in-memory results but you’d still want the subscriptions established on the remote source
(assuming they’ve been disconnected in between)
Dan Gebhardt
@dgeb
Oct 02 2015 20:47
I think liveQuery() just internally calls retrieve then calls query (although the initial retrieve call should be optional via a second arg to liveQuery)
Oliver Searle-Barnes
@opsb
Oct 02 2015 20:47
you’d probably want the model hook to block until you had initial results though
(this is something I’ve also been wondering about)
I think the memory source would do a query and if it hit any relationships that weren’t loaded then it would fail
So you’d return as soon as one of the sources returned results
Dan Gebhardt
@dgeb
Oct 02 2015 20:53
I am not sure this can be generalized. For an async UI, you would want to "show what you've got" immediately. For a sync UI, you'd want to wait until the initial query resolves.
I think a liveQuery could play a part in either scenario - although maybe the name is not the best
Oliver Searle-Barnes
@opsb
Oct 02 2015 20:54
I think subscription is probably clearer
Dan Gebhardt
@dgeb
Oct 02 2015 20:54
yeah, that's pretty good
I like it better too
Oliver Searle-Barnes
@opsb
Oct 02 2015 20:55
So maybe we’re trying too hard to put both queries and liveQueries/subscriptions into one form
Dan Gebhardt
@dgeb
Oct 02 2015 20:55
Subscribable interface with a subscribe method that returns a Subscription
Oliver Searle-Barnes
@opsb
Oct 02 2015 20:56
yeah
sounds simple when you put it like that ;)
Dan Gebhardt
@dgeb
Oct 02 2015 20:56
:D
well done! :clap:
Oliver Searle-Barnes
@opsb
Oct 02 2015 20:56
ha
Dan Gebhardt
@dgeb
Oct 02 2015 20:57
Queryable, Retrievable and Subscribable
I think those work
Oliver Searle-Barnes
@opsb
Oct 02 2015 20:57
yeah, I’m wondering if Retrievable is redundant though
Dan Gebhardt
@dgeb
Oct 02 2015 20:57
ok
Oliver Searle-Barnes
@opsb
Oct 02 2015 20:58
what’s the advantage over just having Queryable?
the UI is promise aware anyway
if it’s in memory it’s going to return just as fast anyway
Dan Gebhardt
@dgeb
Oct 02 2015 20:59
hmmm ... perhaps that extra unnecessary promise + unwanted calls to assist and rescue
Oliver Searle-Barnes
@opsb
Oct 02 2015 20:59
right
Dan Gebhardt
@dgeb
Oct 02 2015 20:59
it just returns what it has
Oliver Searle-Barnes
@opsb
Oct 02 2015 21:00
there was demand for that on ember-data
I’m trying to think where I might want to use it
Dan Gebhardt
@dgeb
Oct 02 2015 21:00
I suppose we could add an optional arg to query
Oliver Searle-Barnes
@opsb
Oct 02 2015 21:00
yeah
Dan Gebhardt
@dgeb
Oct 02 2015 21:00
I would probably use subscribe in most cases instead
Oliver Searle-Barnes
@opsb
Oct 02 2015 21:01
yeah
orbit is fundamentally stream based
Dan Gebhardt
@dgeb
Oct 02 2015 21:01
since it will internally do what I want - retrieve results then query
Oliver Searle-Barnes
@opsb
Oct 02 2015 21:01
right
Dan Gebhardt
@dgeb
Oct 02 2015 21:01
ember-data introduced peek for this purpose
Oliver Searle-Barnes
@opsb
Oct 02 2015 21:01
yeah
Dan Gebhardt
@dgeb
Oct 02 2015 21:01
but it's not very powerful at all
Oliver Searle-Barnes
@opsb
Oct 02 2015 21:02
no, another bolt-on
Dan Gebhardt
@dgeb
Oct 02 2015 21:02
yeah
I figure - why not allow synchronous queries?
Oliver Searle-Barnes
@opsb
Oct 02 2015 21:02
yeah
Dan Gebhardt
@dgeb
Oct 02 2015 21:02
for the subscribe type use case
Oliver Searle-Barnes
@opsb
Oct 02 2015 21:03
I would like subscribe to block if the memory source doesn’t have enough information to satisfy the query (rather than return empty results)
Dan Gebhardt
@dgeb
Oct 02 2015 21:03
seems like we need a few options to subscribe
Oliver Searle-Barnes
@opsb
Oct 02 2015 21:03
possibly that’s an option though...
yeah
Dan Gebhardt
@dgeb
Oct 02 2015 21:03
pretty sure it is
along with whether the initial retrieve is performed at all
Oliver Searle-Barnes
@opsb
Oct 02 2015 21:05
some of these could be specified in the query itself
Dan Gebhardt
@dgeb
Oct 02 2015 21:05
so, the naming is still up in the air a bit
Oliver Searle-Barnes
@opsb
Oct 02 2015 21:05
yeah
Dan Gebhardt
@dgeb
Oct 02 2015 21:05
you mean that query expressions could be sync vs async?
Oliver Searle-Barnes
@opsb
Oct 02 2015 21:05
yeah
Dan Gebhardt
@dgeb
Oct 02 2015 21:05
true
Oliver Searle-Barnes
@opsb
Oct 02 2015 21:05
certainly for the scenarios I’m looking at that makes sense
i.e. you want to show a loading screen while waiting for your main information, but some peripheral things can wait
particularly options for selects and that sort of thing
or maybe comments
Dan Gebhardt
@dgeb
Oct 02 2015 21:07
arguably two different queries though, right?
Oliver Searle-Barnes
@opsb
Oct 02 2015 21:07
well, I suppose I’m still coming from the angle of describing the whole data graph in a single query
Dan Gebhardt
@dgeb
Oct 02 2015 21:07
I see
but let's see - assist and rescue require promises
Oliver Searle-Barnes
@opsb
Oct 02 2015 21:08
the main reason I want to do that is that in our app you would end up with lots of little queries
I think a subscription would keep a reference to the memory source and remote source
Dan Gebhardt
@dgeb
Oct 02 2015 21:09
I just don't see how it knows about the remote source
Oliver Searle-Barnes
@opsb
Oct 02 2015 21:09
right
maybe sources register with a subscription as it’s passed back from the UI
not sure
I’m just not sure if assist and rescue capture enough of the scenarios, possibly
for instance, what happens when you want both sources to load results
neither assist or rescue allow that do they?
they choose one or the other
Dan Gebhardt
@dgeb
Oct 02 2015 21:12
what do you mean by both sources?
Oliver Searle-Barnes
@opsb
Oct 02 2015 21:12
for example, you subscribe, you get the initial results from the memory source but the remote source also opens subscriptions
possibly the store handles that though
i.e. the store has a notion of it’s local data vs other(normally remote) data
so it has enough information to handle that workflow
(hopefully that makes sense - that may have been an obvious point)
Dan Gebhardt
@dgeb
Oct 02 2015 21:14
when the remote source receives data, it should flow back through didTransform
and then the memory source will pick up on relevant changes and update the results in the subscription
I think normalized data needs to flow between sources
it sounds like that is not your vision though
Oliver Searle-Barnes
@opsb
Oct 02 2015 21:16
let’s say a remote source rescues a query, would the subscription return results from the memory source immediately or would it block until the remote source completes?
no, I definitely agree that’s how the data should flow
Dan Gebhardt
@dgeb
Oct 02 2015 21:17
if the remote source returns a promise, then it would block
otherwise the query would fail, and then the subscription would be updated later when the remote source completes
Oliver Searle-Barnes
@opsb
Oct 02 2015 21:18
Right, perhaps I misunderstood, I thought you were suggesting that when subscribing the store would return results immediately and then query the remote source
Dan Gebhardt
@dgeb
Oct 02 2015 21:19
yes, a call to retrieve would initialize the results
and then a call to query would update them
Oliver Searle-Barnes
@opsb
Oct 02 2015 21:19
right
ok, that makes sense
Dan Gebhardt
@dgeb
Oct 02 2015 21:19
(although each could be optional)
Oliver Searle-Barnes
@opsb
Oct 02 2015 21:19
right
Dan Gebhardt
@dgeb
Oct 02 2015 21:20
subscriptions need plenty of options I think
Oliver Searle-Barnes
@opsb
Oct 02 2015 21:20
yup, was just about to say that
it really is on a case by case basis that one
Dan Gebhardt
@dgeb
Oct 02 2015 21:20
we could even have "retry" options and such
Oliver Searle-Barnes
@opsb
Oct 02 2015 21:20
right
Dan Gebhardt
@dgeb
Oct 02 2015 21:21
should query / retrieve be changed to request / retrieve?
they both take query expressions
Oliver Searle-Barnes
@opsb
Oct 02 2015 21:21
right
hmm
Dan Gebhardt
@dgeb
Oct 02 2015 21:21
so it's weird to name only one query
Oliver Searle-Barnes
@opsb
Oct 02 2015 21:21
yeah
how would you describe the difference?
Dan Gebhardt
@dgeb
Oct 02 2015 21:22
I like subscribe at least :)
Oliver Searle-Barnes
@opsb
Oct 02 2015 21:22
it’s async vs sync, but it’s a bit more subtle than that
Dan Gebhardt
@dgeb
Oct 02 2015 21:22
yeah, it also involves assist / rescue
Oliver Searle-Barnes
@opsb
Oct 02 2015 21:22
yeah
as an end user though, what’s the difference?
Dan Gebhardt
@dgeb
Oct 02 2015 21:23
right
Oliver Searle-Barnes
@opsb
Oct 02 2015 21:23
hmm :)
Dan Gebhardt
@dgeb
Oct 02 2015 21:23
you're either retrieving what's inside a source right now, or requesting that source fulfill a query as well as possible
seems like a stretch
Oliver Searle-Barnes
@opsb
Oct 02 2015 21:24
yeah
Dan Gebhardt
@dgeb
Oct 02 2015 21:24
doesn't convey sync vs async well enough
Oliver Searle-Barnes
@opsb
Oct 02 2015 21:24
yeah
so it’s loaded vs ?
store.cached.query vs store.query ?
Dan Gebhardt
@dgeb
Oct 02 2015 21:26
interesting ...
yeah, incorporating the cache in somehow works well
Oliver Searle-Barnes
@opsb
Oct 02 2015 21:28
yeah, I’ve often thought namespacing like that helps clear things up
cached does imply synchronous
Dan Gebhardt
@dgeb
Oct 02 2015 21:29
sure
maybe store.cache.query?
Oliver Searle-Barnes
@opsb
Oct 02 2015 21:30
I thought you might say that ;)
sure
Dan Gebhardt
@dgeb
Oct 02 2015 21:30
since the cache is a thing unto itself
Oliver Searle-Barnes
@opsb
Oct 02 2015 21:30
yeah
makes sense
maybe it literally is the cache
and we implement query against that
probably best not expose everything though
Dan Gebhardt
@dgeb
Oct 02 2015 21:31
yeah, maybe caches are smart enough to handle that
maybe we keep _cache and expose cache with a subset
of methods
not sure
Oliver Searle-Barnes
@opsb
Oct 02 2015 21:31
yeah, I think that makes sense
we don’t want people to hit transform directly on the cache
Dan Gebhardt
@dgeb
Oct 02 2015 21:32
cache is really a CacheProxy
Oliver Searle-Barnes
@opsb
Oct 02 2015 21:32
yeah
expose pretty much takes care of the whole implementation
Dan Gebhardt
@dgeb
Oct 02 2015 21:33
that's true
it's harder to design this stuff than code it :P
Oliver Searle-Barnes
@opsb
Oct 02 2015 21:33
yeah
really
I tried the continuous hacking approach
was definitely not optimal...
Dan Gebhardt
@dgeb
Oct 02 2015 21:33
ha!
yeah, we've all been there
but sometimes it's necessary to figure out the gaps
Oliver Searle-Barnes
@opsb
Oct 02 2015 21:35
yeah, bit of a rude awakening for me, been working server side for so long I don’t think I’d realised how many patterns I was just following
a lot more interesting though
Dan Gebhardt
@dgeb
Oct 02 2015 21:36
hmmm ... yeah we are definitely blazing some trails here
Oliver Searle-Barnes
@opsb
Oct 02 2015 21:36
(client side)
Dan Gebhardt
@dgeb
Oct 02 2015 21:36
agreed
alright - well, I have a pretty clear path now
good discussion!
Oliver Searle-Barnes
@opsb
Oct 02 2015 21:36
yeah, great
I’ll have to figure out the best thing to look at tomorrow
I think I’ll spike out my idea, just support find by id and includes on the querying side
see how far I get (I suspect it’ll raise a whole bunch of new questions)
Dan Gebhardt
@dgeb
Oct 02 2015 21:38
ok that sounds good :)
keep me posted
Oliver Searle-Barnes
@opsb
Oct 02 2015 21:38
will do, it’s going to be an interesting day!
ok, ttys!
Dan Gebhardt
@dgeb
Oct 02 2015 21:38
no doubt!
hasta luego