sferik has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
sferik has joined #rom-rb
snusnu has quit [Quit: Leaving.]
lgierth has joined #rom-rb
skade has quit [Ping timeout: 252 seconds]
sferik has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
skade has joined #rom-rb
sferik has joined #rom-rb
cored has quit [Ping timeout: 264 seconds]
snusnu has joined #rom-rb
skade has quit [Quit: WeeChat 0.4.3]
sferik has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
sferik has joined #rom-rb
<snusnu>
yo mbj, around?
<mbj>
snusnu: jo
<snusnu>
mbj: i'm trying to build support for wrapping wrapped/grouped relations with a gateway into axiom-sql-generator/axiom-do-adapter .. and this somehow relates to the concept of "push down" (not possible to push down with sql)
<snusnu>
so i was wondering if you have any ideas on how to (best) achieve this?
<snusnu>
currently i'm thinking that axiom-do-adapter needs Statement::{Wrap, Group} in order to be able to perform the necessary wrap/group op after the unwrapped/ungrouped relation has been read from the datastore
<snusnu>
i'm thinking that the sql generator should actually simply skip the wrap/group ops, but then "something" has to do it, and it seems to me that the adapter/statement is the best place for it
<snusnu>
i might be missing something, but if i simply skip the wrap/group in axiom-sql-generator, then DO complains about field mismatch, because it sends the correct query but tries to stuff that into a wrapped relation (so fields mismatch)
snusnu has quit [Quit: Leaving.]
snusnu has joined #rom-rb
sferik has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
ahawkins_ has quit [Read error: Connection reset by peer]
ahawkins has quit [Disconnected by services]
ahawkins has joined #rom-rb
snusnu has joined #rom-rb
cored has joined #rom-rb
cored has quit [Changing host]
cored has joined #rom-rb
<snusnu>
yo solnic, around?
<solnic>
snusnu: around yes
<snusnu>
solnic: i'm thinking hard about how it would work that (potentially deeply) wrapped/grouped relations could be wrapped in a gateway
<snusnu>
do you have any thoughts on that, i.e. did you ever think about it?
<solnic>
snusnu: nope
<solnic>
I didn't even think about wrap/group in a gateway
<snusnu>
it's obviously not *really* needed, but it would be *very* nice to be able to define the relation schema with already wrapped/grouped relations
<snusnu>
in its current state, we cannot register wrapped relations in the schema, because axiom-sql-generator generates invalid sql for them
<snusnu>
the way i'd like to use it, is to predefine the relations in the schema as much as possible
<snusnu>
the only thing left for "clients" of these relations, would be to make them context aware, which should mostly mean restricting the relation with a few context dependent predicates
<snusnu>
also, if we have wrapped/grouped relations in the schema, auto inferring mappers for them is a breeze
<solnic>
snusnu: I'm rewritting sql generator so I can think about it later
<snusnu>
but i need it now :o
<solnic>
help me then :P
<snusnu>
i'm afraid my help would be to find a way to make it work in axiom-sql-generator master
<snusnu>
altho actually, my current thoughts evolve more around supporting it in axiom-do-adapter
ahawkins has quit [Read error: Connection reset by peer]
<snusnu>
it seems to me that we would somehow have to recursively skip wrap/group operations (they can't be translated to sql), and then when reading the relation back, somehow reapply those ops
<snusnu>
but so far i can't think of an algorithm that would do the right thing
<solnic>
I'm trying to WRAP my head around joins now
<snusnu>
lol
<solnic>
I wonder how to represent an inner join
<solnic>
left.join(right) { |r| r.id.eq(r.user_id) } <= could translate that into an inner join I suppose
<snusnu>
hmm isn't that a theta join done in memory?
<snusnu>
for practical purposes, it'd be simplest to allow #join to take an optional join_predicates hash (join_definition in dm-mapper times)
<snusnu>
i think the block isn't pushed down to the database?
<snusnu>
i dunno, but somehow i think translating that to an inner join isn't the right thing to do
<solnic>
ok I think you're right
<solnic>
so #join(other, predicates) you think?
<solnic>
and leave block handling as it is now?
<snusnu>
basically, what you need for an inner join, are candidate keys (i.e. primary and unique keys of the involved relations)
<snusnu>
at least i think so
<snusnu>
iirc alf does it that way (it produces inner joins)
<solnic>
left.join(right).on(:id => :user_id) ?
<snusnu>
no, #on would "violate" ra closure property somewhat
<snusnu>
imo the calls you can chain should be valid ra ops only
<solnic>
true dat
<solnic>
left.join(right, :id => :user_id)
<snusnu>
yeah, that's what i meant by join_predicates
<snusnu>
the roles of key/value in the hash are clear, we know what belongs to which relation
<snusnu>
still, i think in most cases, even this info isn't necessary
<snusnu>
because really, you can only (meaningfully) join on keys
<snusnu>
so if you know all keys from both relations, you should be able to do an inner join
<solnic>
there's no way to specify join keys
<snusnu>
atm not
<solnic>
you can specify *keys*
<snusnu>
i guess really, it's about FKs
<solnic>
so we have 2 missing features here
<snusnu>
if you know the FKs involved in the 2 relations, you should be able to construct an inner join?
<solnic>
I don't know any FKs
<solnic>
I know keys :)
<snusnu>
i know
<snusnu>
i'm just trying to think of the info needed to construct an inner join
robmiller has joined #rom-rb
<snusnu>
what you need, is keys of both relations, and you need to match them up, i.e. if a relation has more than one key or a cpk, you need to know the appropriate (c,p)k in the other relation
<snusnu>
which basically means, the FK spanning these 2 relations
<snusnu>
to be precise, the FK constraint
<snusnu>
if you can get at an FK constraint involving the relations to be joined, you can surely construct an inner join
<solnic>
yeah man I know that
<solnic>
I need to figure out how to implement that in axiom nw
<solnic>
now
<snusnu>
imo we should add the concept of FK constraints
<solnic>
any api ideas?
<snusnu>
i need to dig them up, iirc i sketched it back in the days
<solnic>
you mean the schema?
<snusnu>
yeah, that's stuff belonging to the schema definition i think
<snusnu>
because it spans 2 relations
<snusnu>
but in the meantime, you could start with Relation#join(other, join_predicates = {})
ahawkins has quit [Read error: Connection reset by peer]
<solnic>
snusnu: thanks
<solnic>
I'll work on it this week
<solnic>
gotta go to sleep now
<solnic>
good night!
<snusnu>
solnic: ok have a good night, i'm atm beginning to question the gateway idea btw
<snusnu>
:)
<solnic>
snusnu: ok?
<solnic>
snusnu: please continue
<solnic>
I'm starting to think inner/outer joins should be added via axiom-sql gem (that would also include a generator)
<snusnu>
solnic: i dunno, i'm having a hard time thinking up an algorithm for wrapped/grouped gateway relations, and given that alf somehow does it, and doesn't seem to have the concept of a gateway relation … nevermind
<solnic>
yeah let's talk about it at some point but soon
<snusnu>
yeah, i'll give it a bit more thought for sure, i really want to have that feature and it must be possible :)
<solnic>
ok, this time I will go
<solnic>
and please don't write anything intriguing now
<solnic>
nite :D
<snusnu>
the closure of the ra ops makes me thing, theoretically it should be possible to do people.join(accounts).wrap(account: [:id, :login]).project(:name, :login)
<snusnu>
but i wonder how to "flatten out" all the wraps/groups .. producing the correct still, and afterwards (*before* yielding the tuples) reapply the ops
<snusnu>
this seems like it needs to happen within the gateway relation, but i can't think of how
<solnic>
you really don't want me to get some proper sleep now do you ;)
<snusnu>
was that intriguing?
<snusnu>
;)
<snusnu>
naw man get some sleep, unless you know something i don't :)
<solnic>
boring stuff I'm gonna go to sleep now YAAAWWNNN