<solnic>
dkubb: I tried looking through mutant code to see if it supports filtering namespaces but haven’t found anything except a config setting called “filter” which does absolutely nothing ;)
<dkubb>
solnic: I usually trace that kind of stuff by starting at the CLI code
<solnic>
I didn’t dive deep tbh
<dkubb>
solnic: as you've probably guessed in my work campfire, there's a bit of a shit-storm with one of our client's machines. I'll probably need to rebuild it (finally, we've been asking to do that since we started working with them). I don't know how much oss time I'll have, but I'll still try to do as much as I possibly can
<solnic>
dkubb: yeah no worries
<dkubb>
solnic: you said you needed update more than anything in ROM?
<dkubb>
solnic: I could work on update and defer group/ungroup
<solnic>
dkubb: would be nice to have #update
<solnic>
yeah group/ungroup is less important because we don’t support loading relationships yet anyway
<solnic>
from ROM pov
<dkubb>
yeah
<dkubb>
that's what I was thinking too
<snusnu>
but it would *greatly* simplify loading of "faked" relationships
<dkubb>
it'd be nice to have now, but it seems like update is more important
<dkubb>
then maybe adapter generated defaults
<snusnu>
we cannot map joined models without "crazy" tuple collapsing stuff like we had in dm-mapper tho
<snusnu>
without #group #ungroup
<dkubb>
some of the tuple collapsing stuff is probably just getting pushed down to axiom :)
<snusnu>
true too
<dkubb>
it's not crazy though. my Group#each method is like 10 loc before refactoring
<dkubb>
I have all the code inlined while I tested it
<snusnu>
yeah i know, but i hated that code in dm-mapper ;)
<dkubb>
I think I can factor it out into an object responsible for building an index
<dkubb>
I can use that object in join and group I think
<snusnu>
fair enough tho, i'm not gonna press for #group #ungroup
<dkubb>
I would love to add it
<dkubb>
I just want to make sure I'm supporting what ROM needs most
<dkubb>
I'll let ROM be my "client"
<snusnu>
awesome hah, yeah, i'm kinda torn .. probably it's better to "fake" more easy things in rom for now, like that grouping
<solnic>
we agreed to focus on foundation
<solnic>
update is kinda…foundational
<solnic>
group not really
<dkubb>
I think it will be once we have relationships in ROM
<solnic>
yes but we don’t :)
<dkubb>
I would expect more than half the queries executed use group
<dkubb>
yeah
<dkubb>
group will likely be used like include() is in AR
<solnic>
my point is that first release should be IMHO targeted at developers wanting to get involved and writing adapters is a great way of doing so
<solnic>
so, if we don;t have update it will suck
<snusnu>
good point
<solnic>
btw it sucks we still don’t have a unified gateway/abstract adapter :)
<solnic>
something to resolve during eurucamp...
<dkubb>
I might be able to write a quick and dirty update that does the delete/insert under the hood, but exposes the api I want.. and then work on a v2 of it that does things more efficiently
<dkubb>
I think we'll need to write more adapters before we can unify the gateways
<solnic>
dkubb: hmm we have…5 already
<dkubb>
and an abstract adapter isn't that critical. the gateway is the only thing that talks to the adapter
<dkubb>
I wouldn't say that's enough
<solnic>
really?
<dkubb>
they all have vastly different needs from the adapter
<dkubb>
yeah
<dkubb>
some push-down, some do other things. the memory adapter doesn't even have a gateway
<dkubb>
although I want to add one
<solnic>
hmm why do we need more to unify it?
<dkubb>
you could, concievably, have completely different adapter APIs as long as the gateway matches the interface
<dkubb>
the gateway is the point of integration
<solnic>
oh I think adapters will expose different interfaces
<dkubb>
don't get me wrong, I do like the idea of having adapters that are as close as possible, just for consistencies
<solnic>
given different datastore features
<solnic>
and different db driver features
<solnic>
I’m more talking about the proxy thing
<dkubb>
the memory adapter doesn't have #read, #create, #update, or #delete I think. it just relies on #[] and #[]=
<solnic>
I know we can’t have one interface to rule them all ;)
<dkubb>
I think adapters should expose #[] and #[]= though
<dkubb>
and probably #each that enumerates over all the relations it knows about
mbj has joined #rom-rb
<dkubb>
if I was going to make an abstract adapter I would probably define those three methods as abstract methods, and then make sure other adapters implement them
<dkubb>
mbj and I have written most of the adapters so we should try to come up with, at least, an abstract base class for the gateway
<dkubb>
if we have something common as a base we can continue to push things up to it until our gateway objects do nothing more than inherit from the base class
<solnic>
that’s what would be great
<dkubb>
I don't really want to try to jump all the way to total unification in one step
<solnic>
otherwise a newcomer wanting to write an adapter will look like that: O_o when looking at gateway classes with proxy stuff
<dkubb>
if we knew the solution now, then maybe, but right now I don't know if we're all sure about how it'll work
<dkubb>
we can gradually move to the point where a new adapter's gateway can be configured via some kind of dsl to describe what operations need to be pushed down, and which ones can be handled
<dkubb>
that would be my ideal
<solnic>
true
<mbj>
dkubb: +1 for removing cross adapter duplication
<mbj>
using flay cross repos is really interesting.
mbj has quit [Read error: Connection reset by peer]