These are chat archives for orbitjs/orbit.js

27th
Feb 2016
Oliver Searle-Barnes
@opsb
Feb 27 2016 10:21
@dgeb I’ve started having a look at an RxJS based coordinator. Regarding the blocking behaviour, are you expecting to block until all side-effects of the original transform have propagated? e.g. if a JSON API request responds with additional transforms (remote-id) should the original transform block until those have also been incorporated into the Cache?
Oliver Searle-Barnes
@opsb
Feb 27 2016 11:46
Am I also right in thinking that transforms should only be applied to the Cache after they’ve transformed the remote source?
Dan Gebhardt
@dgeb
Feb 27 2016 14:31
@opsb this is a question of tracking causality
from the store perspective, we need the option to only resolve a transform once all of its side effects have propagated
orbit has traditionally handled this via promise-aware events at the source level
in which interested parties can participate in transforms by listening to events and returning a promise
and source won't resolve the transform promise without first resolving listener promises
which allows for a blocking scenario, all the way up to the UI
Dan Gebhardt
@dgeb
Feb 27 2016 14:37
I don't see a reason to drop promise-aware events from orbit - they allow sources to be wired up either with or without a complex coordinator
Oliver Searle-Barnes
@opsb
Feb 27 2016 14:52
On Transformables promises are used to indicate to indicate whether they have processed a Transform and any side effects. With confirmation based coordinators the blocking behaviour still needs to be defined at the coordinator level. Do I understand correctly then that you'd prefer that coordinators block until all side effects have also been confirmed?
Dan Gebhardt
@dgeb
Feb 27 2016 15:06
I think that conventionally we'll be using coordinators as the only listeners of transform events
and that the sources that represent side effects will be wired through the coordinators
rather than directly to sources themselves
is there something about that approach that conflicts with your work on confirmation based coordinators?
Oliver Searle-Barnes
@opsb
Feb 27 2016 15:10
That seems fine, there's a few fuzzy areas but perhaps it's best to push some code up and talk about a concrete example. Out at the moment but I'll push up what I've got so far when I get back.
Dan Gebhardt
@dgeb
Feb 27 2016 15:12
ok, cool - I'll be pretty unavailable for the next few hours (giving a talk for the online "global ember meetup")
ttys
Oliver Searle-Barnes
@opsb
Feb 27 2016 15:13
Ah, I should really check that out at some point, is it weekly?
Dan Gebhardt
@dgeb
Feb 27 2016 15:13
pretty sure it's monthly
this is my first
Oliver Searle-Barnes
@opsb
Feb 27 2016 15:13
Right
Oliver Searle-Barnes
@opsb
Feb 27 2016 17:13
@dgeb I’ve pushed up where I’ve got to orbitjs/orbit.js#264
bear in mind that this is still very much a spike at the moment, it’s a long way off a finished version
The basic idea of a confirmation step is there at least anyway. The pipeline in particular is very limited in this basic scenario, it’s value should become clearer as more complex requirements are introduced.
The plan is to now gradually introduce requirements into this scenario and generalise.
I’d like to get error handling done on this first connector but then I’m going to start on the optimistic coordinator. At that point it should start to become clear how best to generalise.
Oliver Searle-Barnes
@opsb
Feb 27 2016 20:36
I’ve been considering how to track transforms that have created new transforms as side-effects when applied to Sources.
Somehow the confirmation step needs to know to wait for these “child” transforms.
They’ll follow the original transform so the information can’t be included on them.
I see two options:
1) On the same TransformTracker that I’m using to determine when transforms have been confirmed
2) On the original transform
(1) would require exposing the relationship between the transforms through the Transformable api somehow e.g.
source
  .transform(transform)
  .then(childTransforms => {})
Oliver Searle-Barnes
@opsb
Feb 27 2016 20:43
(2) would possibly be simpler, I’ve been considering mutable meta data on a Transform since our last discussion regarding “hinting” for specific Sources e.g. requesting a refresh after a transformation in the JSON API Source.
BTW I caught your engines update on the global meetup, lazy-loading does indeed sound very interesting!
Dan Gebhardt
@dgeb
Feb 27 2016 21:03
ok, I am back ... need to catch up
Oliver Searle-Barnes
@opsb
Feb 27 2016 21:03
that was quite a session on the EGM
missed Tom's fastboot bit, sounds like the code dive was interesting
Dan Gebhardt
@dgeb
Feb 27 2016 21:04
egm ... more like omg :P
3.5 hours
Oliver Searle-Barnes
@opsb
Feb 27 2016 21:04
ha
epic
Dan Gebhardt
@dgeb
Feb 27 2016 21:04
yeah, Tom's talk was great
really a good deep dive
Oliver Searle-Barnes
@opsb
Feb 27 2016 21:04
been very fuzzy on how fastboot is going to work so it’ll be great to have a good look at the architecture
Dan Gebhardt
@dgeb
Feb 27 2016 21:05
yeah, I won't try to summarize here - just watch Tom's talk - it's really good :)
soooo ... back to orbit
we have to track causality between transforms
Oliver Searle-Barnes
@opsb
Feb 27 2016 21:10
yes
Dan Gebhardt
@dgeb
Feb 27 2016 21:10
just reviewing
so we could add meta data to each transform
Oliver Searle-Barnes
@opsb
Feb 27 2016 21:10
yeah, that does seem the simplest path
I’ve been trying to avoid mutating them
But perhaps there’s a case for having mutable/immutable parts to the transform
Dan Gebhardt
@dgeb
Feb 27 2016 21:11
what about emitting a TransformResult instead of just a Transform?
Oliver Searle-Barnes
@opsb
Feb 27 2016 21:11
Weak references(a set of child parent ids) seems the most appealing at the moment
I thought you might mention that ;)
Dan Gebhardt
@dgeb
Feb 27 2016 21:11
ha!
Oliver Searle-Barnes
@opsb
Feb 27 2016 21:12
it’s definitely an option
Dan Gebhardt
@dgeb
Feb 27 2016 21:12
on('transform') emits a transform + transformResult
on('query') emits a query + queryResult
Oliver Searle-Barnes
@opsb
Feb 27 2016 21:13
I find keeping the relationship in the data model quite appealing (including child ids on the parent), it scales to trees of side effects nicely
I don’t have a firm opinion here yet though
With the transformResult approach I think we’d need a separate data structure which tracked all of the relationships between the transforms
(I was considering using the TransformTracker for this)
Dan Gebhardt
@dgeb
Feb 27 2016 21:15
yes, a git log of sorts
Oliver Searle-Barnes
@opsb
Feb 27 2016 21:15
yeah
so I think it comes down to where we want to store the relationships, in the Transform(child transforms on parent) or externally(transformResult)

If we were to go with transformResult I think

const transformResult = source.transform(transform);

might work better than emitting it

Dan Gebhardt
@dgeb
Feb 27 2016 21:17
I was suggesting both
so transform returns a promisified result
and on('transform') emits a result
I am not sure that TransformResult is the right approach here tbh
Oliver Searle-Barnes
@opsb
Feb 27 2016 21:20
I think that would work fine for transformResult.
yeah, I agree
feels like the data model should handle this
Dan Gebhardt
@dgeb
Feb 27 2016 21:20
we need a data model that includes causality
Oliver Searle-Barnes
@opsb
Feb 27 2016 21:20
agreed
I did wonder about transforms of transforms
Dan Gebhardt
@dgeb
Feb 27 2016 21:21
right
Oliver Searle-Barnes
@opsb
Feb 27 2016 21:21
they’d need flattening for processing
but yeah, that could work, looking for issues with that approach at the moment
Dan Gebhardt
@dgeb
Feb 27 2016 21:23
I also would like Transforms to remain immutable
Oliver Searle-Barnes
@opsb
Feb 27 2016 21:23
yeah, that is definitely nice
Dan Gebhardt
@dgeb
Feb 27 2016 21:24
do we need a concept of an AppliedTransform?
which is per-source?
Oliver Searle-Barnes
@opsb
Feb 27 2016 21:24
new Transform([originalTransform, sideEffectTransform])
I think Transform trees might work well actually
it would mean we could just emit a Transform as we currently do
Dan Gebhardt
@dgeb
Feb 27 2016 21:26
yeah
Oliver Searle-Barnes
@opsb
Feb 27 2016 21:26
transform.operations could handle flattening them for processing
actually during processing we’d need to still chunk them as transforms so that we know when not to reapply
Dan Gebhardt
@dgeb
Feb 27 2016 21:27
right - they need to retain their identity
like commits
Oliver Searle-Barnes
@opsb
Feb 27 2016 21:28
yeah
I think we should probably avoid circular networks (of sources)
Dan Gebhardt
@dgeb
Feb 27 2016 21:28
i.e. two-way transform connectors?
Oliver Searle-Barnes
@opsb
Feb 27 2016 21:28
yeah
well, I suppose the logs will prevent things getting too complicated
just means that conflicts are likely
I’m considering the scenario:
sourceA.transform(transformA)
sourceB.transform(transformA) => transformC([transformA, transformB])
sourceA.transform(transformC)
Dan Gebhardt
@dgeb
Feb 27 2016 21:32
so our goal here is to define the result needed to be returned from transform and emitted by on('transform')
I think we agree that they should be the same
Oliver Searle-Barnes
@opsb
Feb 27 2016 21:32
yeah
Dan Gebhardt
@dgeb
Feb 27 2016 21:33
the result needs to include other transforms that result from the applied transform, right?
Oliver Searle-Barnes
@opsb
Feb 27 2016 21:33
yes
Dan Gebhardt
@dgeb
Feb 27 2016 21:33
because we need a single promise to indicate that a request is complete
so that we can track this promise all the way back to the UI
like say we're submitting a payment
Oliver Searle-Barnes
@opsb
Feb 27 2016 21:34
yes
Dan Gebhardt
@dgeb
Feb 27 2016 21:34
we need all the resulting transforms to be "done" by the time that request completes
so that means the source's own transform needs to return a promisified "result"
Oliver Searle-Barnes
@opsb
Feb 27 2016 21:35
we also need the result to be applied to the next Source
(that’s better)
Dan Gebhardt
@dgeb
Feb 27 2016 21:37
so that is effectively merging a branch of commits
Oliver Searle-Barnes
@opsb
Feb 27 2016 21:37
it’s also worth considering that the UI concern of tracking the transform is only relevant when the UI created the transform
Dan Gebhardt
@dgeb
Feb 27 2016 21:37
I think I agree there
Oliver Searle-Barnes
@opsb
Feb 27 2016 21:38
when the transform is streamed into the Source no tracking is required for the UI
right
so that is effectively merging a branch of commits
that’s a good way of putting it
Dan Gebhardt
@dgeb
Feb 27 2016 21:38
it is an array of commits, not a tree, right?
Oliver Searle-Barnes
@opsb
Feb 27 2016 21:38
was just pondering that
it is
Dan Gebhardt
@dgeb
Feb 27 2016 21:39
it represents only transforms coming from a single source
even if other sources trigger those transforms
ok, so we agree?
Oliver Searle-Barnes
@opsb
Feb 27 2016 21:40
yes, I think so
ok, so we can just keep references to the parent in the new commits/transforms
however, this doesn’t get us causality
I don’t think...
Dan Gebhardt
@dgeb
Feb 27 2016 21:41
I don't know about tracking the parent
Oliver Searle-Barnes
@opsb
Feb 27 2016 21:41
yeah
Dan Gebhardt
@dgeb
Feb 27 2016 21:41
the order is important
Oliver Searle-Barnes
@opsb
Feb 27 2016 21:42
yes
Dan Gebhardt
@dgeb
Feb 27 2016 21:42
an array of transforms needs to be emitted
Oliver Searle-Barnes
@opsb
Feb 27 2016 21:42
although if they’re chained then that works
Dan Gebhardt
@dgeb
Feb 27 2016 21:42
true
Oliver Searle-Barnes
@opsb
Feb 27 2016 21:42
the problem is that you can’t tell which transforms caused which transforms
if you join new transforms onto the end of the chain anyway
perhaps that isn’t necessary though
perhaps we just emit the last transform in the chain
and the next source does a merge
Dan Gebhardt
@dgeb
Feb 27 2016 21:44
what are you suggesting on('transform') emits?
Oliver Searle-Barnes
@opsb
Feb 27 2016 21:44
(so it finds the common parent and applies the children in sequence)
Dan Gebhardt
@dgeb
Feb 27 2016 21:44
a simple array of transforms?
that should be applied in order?
Oliver Searle-Barnes
@opsb
Feb 27 2016 21:44
I was thinking it could emit a single transform, whose history includes the original transform and any new children
(with a link to the parent on each transform)
thinking about git a lot here obviously
Dan Gebhardt
@dgeb
Feb 27 2016 21:45
right, it's a good model here
Oliver Searle-Barnes
@opsb
Feb 27 2016 21:46
yeah
I think it’s fair to say the git model has proven itself ;)
Dan Gebhardt
@dgeb
Feb 27 2016 21:46
indeed ;)
so what does your approach buy us over just an array of transforms?
from the source's perspective?
Oliver Searle-Barnes
@opsb
Feb 27 2016 21:47
well, there’s conflict detection built in
the histories have to match
Dan Gebhardt
@dgeb
Feb 27 2016 21:48
I think this is right to track at the coordinator
but I'm unclear about the need at the source
the history is all clear from the array of transforms, right?
and then they can remain immutable
Oliver Searle-Barnes
@opsb
Feb 27 2016 21:49
it has a horizon though
it starts when a transform is created in the UX
it’s disconnected from the existing history
Dan Gebhardt
@dgeb
Feb 27 2016 21:50
let's get concrete here
Oliver Searle-Barnes
@opsb
Feb 27 2016 21:50
what happens when you apply the array of transforms at the next Source, which maybe also produces side effects?
Dan Gebhardt
@dgeb
Feb 27 2016 21:51
we would want a hub-and-spoke model with the coordinator as the hub, right?
Oliver Searle-Barnes
@opsb
Feb 27 2016 21:52
it is worth considering that we’re dealing with incomplete histories though
yeah
Dan Gebhardt
@dgeb
Feb 27 2016 21:52
we wouldn't want to connect 2-way transform connectors
Oliver Searle-Barnes
@opsb
Feb 27 2016 21:52
I don’t think so no
Dan Gebhardt
@dgeb
Feb 27 2016 21:53
it's possible to connect a 1-way connector to stream data somewhere
but it's not going to work any more to have 2-way connectors
Oliver Searle-Barnes
@opsb
Feb 27 2016 21:53
I don’t see why not, or vica versa
hard to see how 2-way connectors will work with logs
Dan Gebhardt
@dgeb
Feb 27 2016 21:54
so you agree that sources directly connected to each other should only move data in one direction, right?
Oliver Searle-Barnes
@opsb
Feb 27 2016 21:54
yes, that does seem to simplify things
make them manageable even :)
Dan Gebhardt
@dgeb
Feb 27 2016 21:54
yes
otherwise you need a coordinator
this is the mistake made with the original orbit design
Oliver Searle-Barnes
@opsb
Feb 27 2016 21:55
yeah, that did make it unstable
Dan Gebhardt
@dgeb
Feb 27 2016 21:55
2-way connectors could lock up queues
Oliver Searle-Barnes
@opsb
Feb 27 2016 21:55
was certainly an education ;)
Dan Gebhardt
@dgeb
Feb 27 2016 21:55
ugh
I am sorry I didn't think it through better at first
Oliver Searle-Barnes
@opsb
Feb 27 2016 21:56
well, best way to learn
Dan Gebhardt
@dgeb
Feb 27 2016 21:56
true
Oliver Searle-Barnes
@opsb
Feb 27 2016 21:56
I’ve certainly got a “feel” for distributed systems now
Dan Gebhardt
@dgeb
Feb 27 2016 21:56
:)
so I'm not sure sources need to do anything other than emit arrays of immutable transforms, and coordinators can wire together a log from each source
and then perform merges for instance
that seems simplest from the Source perspective
Oliver Searle-Barnes
@opsb
Feb 27 2016 21:58
I’m wondering if we should have a single data model that handles everything
rather than leave it up to the coordinators
seems like we’d have a stronger system if we could define a data model
that does require getting the data model right though :)
Dan Gebhardt
@dgeb
Feb 27 2016 22:00
lol
I'll need to be convinced that it's worthwhile for sources to do that extra work
I'm not against it, just trying to keep sources as simple as possible
Oliver Searle-Barnes
@opsb
Feb 27 2016 22:01
I’m not sure it is any extra work for them
I suppose they need to find a common parent in the logs
the transform-log abstraction could probably handle that
Dan Gebhardt
@dgeb
Feb 27 2016 22:02
does each source really need an internal log?
or could that log be kept at the coordinator?
Oliver Searle-Barnes
@opsb
Feb 27 2016 22:03
hmm
Dan Gebhardt
@dgeb
Feb 27 2016 22:03
like the queues
Oliver Searle-Barnes
@opsb
Feb 27 2016 22:03
well, it certainly can be, yes
so we’d effectively have a data structure with transforms in it
Dan Gebhardt
@dgeb
Feb 27 2016 22:04
right
we could have a single map of transforms
and the coordinator could maintain a log for each source
as well as a queue
effectively managing each "branch"
Oliver Searle-Barnes
@opsb
Feb 27 2016 22:05
yes
Dan Gebhardt
@dgeb
Feb 27 2016 22:05
then the data is not spread far and wide
the coordinator's logs / data could be cleared by consensus events
Oliver Searle-Barnes
@opsb
Feb 27 2016 22:06
the only issue I’ve come across with centralised model is that the lifecycle of the logs should be aligned with the lifecycle of the sources
e.g. the localstorage log should be persisted in localstorage
as opposed to the memorysource log
when we reload the browser how do we get the coordinator into the correct state
this is different to the queues, they can always be thrown away
A thornier question is, how do we match up the localstorage log with the remote log?
Dan Gebhardt
@dgeb
Feb 27 2016 22:10
I think we need to figure out a persistence strategy for the coordinator
i.e. it has data of its own
that is above and beyond what gets copied to browser storage
Oliver Searle-Barnes
@opsb
Feb 27 2016 22:13
hmm
Dan Gebhardt
@dgeb
Feb 27 2016 22:13
I don't really think we need to solve this yet
Oliver Searle-Barnes
@opsb
Feb 27 2016 22:14
perhaps not
I do think that logs probably need to be stored in the Sources though
although I’m grappling with how that will work for remote sources like JSON API
Dan Gebhardt
@dgeb
Feb 27 2016 22:15
if the coordinator is managing queues for sources, why not logs as well?
Oliver Searle-Barnes
@opsb
Feb 27 2016 22:15
because the logs are tightly coupled with the data in the sources
the queues just represent information that hasn’t been integrated yet
Dan Gebhardt
@dgeb
Feb 27 2016 22:16
the queues represent transforms tbd, and the logs represent transforms done
Oliver Searle-Barnes
@opsb
Feb 27 2016 22:16
the source includes transforms done though
the logs and information in the Source can’t drift
the transforms TBD can be changed independently of the information in the Source and the log
Dan Gebhardt
@dgeb
Feb 27 2016 22:19
I don't disagree, but I'm not sure any of this is meaningful to any piece of the puzzle other than the coordinator
Oliver Searle-Barnes
@opsb
Feb 27 2016 22:19
I don’t see why it can’t be handled in the coordinator it’s true
Dan Gebhardt
@dgeb
Feb 27 2016 22:20
these logs will certainly need to be truncated, for instance
Oliver Searle-Barnes
@opsb
Feb 27 2016 22:20
sure
so what about when the browser is refreshed? how do we bring localstorage and a remote source into sync?
so let’s say the coordinator has a log for both
stored in localstorage
when the browser is refreshed the log for the remote source could be out of date
(I’m thinking the streaming source more here perhaps)
Dan Gebhardt
@dgeb
Feb 27 2016 22:22
right - so the coordinator has a means to store all the data it will need in browser storage
Oliver Searle-Barnes
@opsb
Feb 27 2016 22:22
I realise this is looking forward a bit, but I don’t want to paint ourselves into a corner
yes, it does seem that way
Dan Gebhardt
@dgeb
Feb 27 2016 22:23
the coordinator needs to merge the localstorage "branch" into the remote "branch"
Oliver Searle-Barnes
@opsb
Feb 27 2016 22:23
right
Dan Gebhardt
@dgeb
Feb 27 2016 22:24
so it needs to save those transforms in browser storage as well as the logs for both sources
and then apply those transforms to the remote source
as a "merge"
Oliver Searle-Barnes
@opsb
Feb 27 2016 22:25
it seems that we’d need the app developer to decide how to do that “merge"
or do we just assume the remote source is fresher?
Dan Gebhardt
@dgeb
Feb 27 2016 22:26
I think we need all sorts of knobs / levers to customize the coordinator strategy
Oliver Searle-Barnes
@opsb
Feb 27 2016 22:27
ok, so where does this leave us?
Dan Gebhardt
@dgeb
Feb 27 2016 22:27
so getting back to the Source
Oliver Searle-Barnes
@opsb
Feb 27 2016 22:28
yes
so the Source is going to be pretty dumb
Dan Gebhardt
@dgeb
Feb 27 2016 22:28
that's my hope
I want them to be easy to write
Oliver Searle-Barnes
@opsb
Feb 27 2016 22:28
right
Dan Gebhardt
@dgeb
Feb 27 2016 22:29
source.transform() returns a promisified array of transforms?
Oliver Searle-Barnes
@opsb
Feb 27 2016 22:29
yeah, that does seem to be all we need then
Dan Gebhardt
@dgeb
Feb 27 2016 22:29
that includes the applied transform?
Oliver Searle-Barnes
@opsb
Feb 27 2016 22:29
I’m not sure we even need to include that
unless we’re going to allow it to be applied in the middle of the sequence
Dan Gebhardt
@dgeb
Feb 27 2016 22:29
^ interesting
on('transform') will need to emit an array of transforms
maybe it doesn't need to separate out the "applied" one
Oliver Searle-Barnes
@opsb
Feb 27 2016 22:30
do we need on(’transform’) ?
Dan Gebhardt
@dgeb
Feb 27 2016 22:30
what about for a socket-source?
Oliver Searle-Barnes
@opsb
Feb 27 2016 22:30
we could just provide coordinators that handle every setup
ah, true :)
Dan Gebhardt
@dgeb
Feb 27 2016 22:31
so, can they both just emit the same array?
Oliver Searle-Barnes
@opsb
Feb 27 2016 22:31
if they include the original, yes
Dan Gebhardt
@dgeb
Feb 27 2016 22:32
that seems good to me
Oliver Searle-Barnes
@opsb
Feb 27 2016 22:32
yeah, I think that’s fine
leaves a lot for the coordinators to do :)
but that doesn’t seem to be a problem either
Dan Gebhardt
@dgeb
Feb 27 2016 22:33
I think we have a lot of benefits in centralization
Oliver Searle-Barnes
@opsb
Feb 27 2016 22:33
I suspect we might end up devolving some responsibilities to the Sources but we can see how it goes
Dan Gebhardt
@dgeb
Feb 27 2016 22:33
ok, let's keep our minds open
the important thing is that it's really easy to write a Source
Oliver Searle-Barnes
@opsb
Feb 27 2016 22:33
yes
Dan Gebhardt
@dgeb
Feb 27 2016 22:33
and each source uses a minimal amount of memory
Oliver Searle-Barnes
@opsb
Feb 27 2016 22:34
so, immutable.js? :)
one for another day probably ;)
Dan Gebhardt
@dgeb
Feb 27 2016 22:34
you mean, use immutable.js?
I don't want to use FB projects really
Oliver Searle-Barnes
@opsb
Feb 27 2016 22:35
just thinking about the actual data store, I suppose we don’t really have any caching going on in the sources now though
ha!
I feel fairly neutral on the matter, can take them or leave them
Dan Gebhardt
@dgeb
Feb 27 2016 22:35
so I'm working on transform builders
Oliver Searle-Barnes
@opsb
Feb 27 2016 22:35
right
Dan Gebhardt
@dgeb
Feb 27 2016 22:36
I have a WIP branch
Oliver Searle-Barnes
@opsb
Feb 27 2016 22:36
yeah, that will be nice
Dan Gebhardt
@dgeb
Feb 27 2016 22:36
yeah
Oliver Searle-Barnes
@opsb
Feb 27 2016 22:36
I’ve actually found myself wishing for them a few times since you mentioned them
Dan Gebhardt
@dgeb
Feb 27 2016 22:36
so nothing to discuss there - it's very straightforward actually - just need to finish
Oliver Searle-Barnes
@opsb
Feb 27 2016 22:36
great
Dan Gebhardt
@dgeb
Feb 27 2016 22:36
so let's talk about queries
if you have a minute
Oliver Searle-Barnes
@opsb
Feb 27 2016 22:36
yeah, ok
sure
Dan Gebhardt
@dgeb
Feb 27 2016 22:37
gah, sorry, one sec
Oliver Searle-Barnes
@opsb
Feb 27 2016 22:38
no worries
Dan Gebhardt
@dgeb
Feb 27 2016 22:39
I am back to considering a QueryResult
that can contain a lean cache of its own normalized data
Oliver Searle-Barnes
@opsb
Feb 27 2016 22:40
right
Dan Gebhardt
@dgeb
Feb 27 2016 22:40
so sources don't need to construct transforms themselves
Oliver Searle-Barnes
@opsb
Feb 27 2016 22:41
you’ve lost me there
Dan Gebhardt
@dgeb
Feb 27 2016 22:41
well, we discussed returning an array of transforms from query
Oliver Searle-Barnes
@opsb
Feb 27 2016 22:41
right
you’re proposing we return the QueryResult instead?
Dan Gebhardt
@dgeb
Feb 27 2016 22:42
yeah
Oliver Searle-Barnes
@opsb
Feb 27 2016 22:42
ok, that does make sense :)
hmm
Dan Gebhardt
@dgeb
Feb 27 2016 22:42
I need to think about the interface more though
glad you're in general agreement
I've got to run actually
Oliver Searle-Barnes
@opsb
Feb 27 2016 22:43
don’t we need to convert QueryResult to transforms anyway to integrate the data?
Dan Gebhardt
@dgeb
Feb 27 2016 22:43
so we can leave this for another day
Oliver Searle-Barnes
@opsb
Feb 27 2016 22:43
sure
ok, that’s enough for me to continue on the coordinators anyway
Dan Gebhardt
@dgeb
Feb 27 2016 22:43

don’t we need to convert QueryResult to transforms anyway to integrate the data?

yeah, I think the QueryResult can do this itself

ok, that’s enough for me to continue on the coordinators anyway

ok, great - ttys :)

Oliver Searle-Barnes
@opsb
Feb 27 2016 22:44
ttys