skade has quit [Quit: Computer has gone to sleep.]
skade has joined #rom-rb
mbj has quit [Ping timeout: 272 seconds]
kleech has joined #rom-rb
AndrzejKrzywda has left #rom-rb [#rom-rb]
mbj has joined #rom-rb
mbj has quit [Ping timeout: 272 seconds]
skade has quit [Ping timeout: 272 seconds]
zekefast has joined #rom-rb
zekefast has quit [Client Quit]
skade has joined #rom-rb
skade has quit [Ping timeout: 240 seconds]
postmodern has quit [Quit: Leaving]
zekefast has joined #rom-rb
cored has joined #rom-rb
skade has joined #rom-rb
kleech has quit [Remote host closed the connection]
kleech has joined #rom-rb
kleech has quit [Ping timeout: 248 seconds]
breakingthings has joined #rom-rb
kleech has joined #rom-rb
snusnu has joined #rom-rb
skade has quit [Quit: Computer has gone to sleep.]
snusnu has quit [Quit: Leaving.]
cored has quit [Ping timeout: 265 seconds]
CraigBuchek has joined #rom-rb
snusnu has joined #rom-rb
cored has joined #rom-rb
cored has joined #rom-rb
cored has quit [Ping timeout: 245 seconds]
cored has joined #rom-rb
skade has joined #rom-rb
cored has quit [Remote host closed the connection]
knowtheory has quit [Ping timeout: 256 seconds]
cored has joined #rom-rb
cored has joined #rom-rb
cored has quit [Ping timeout: 240 seconds]
mkristian has joined #rom-rb
zekefast has quit [Ping timeout: 245 seconds]
mkristian_ has joined #rom-rb
zekefast has joined #rom-rb
mkristian has quit [Ping timeout: 272 seconds]
dkubb has joined #rom-rb
<snusnu>
hey dkubb
<snusnu>
dkubb: thx a lot for #wrap/#unwrap! that was fast!
<dkubb>
snusnu: good morning
<dkubb>
yeah it wasn't too hard once I sat down to do it
<snusnu>
dkubb: i'm currently trying to integrate #group with rom-relation
<dkubb>
cool
<snusnu>
dkubb: it will currently involve quite some "handwritten" mapper stuff to get it working, but we'll see how that evolves eventually
<dkubb>
snusnu: yeah, I would assume the raw ops would be added first, and then association specific stuff would be added next?
zekefast has quit [Quit: Leaving.]
zekefast has joined #rom-rb
<snusnu>
dkubb: yeah, rom-relation specs currently rely on a handwritten mapper that simply supports #load(tuple) and #dump(object) .. i'm currently playing around with writing a specific mapper that knows how to map an EC .. it's tailored to specific models tho
<snusnu>
dkubb: i'm planning to write a few of those handwritten mappers (probably using ducktrap under the hood) in my app .. and then i'll know a bit more about what's needed
<dkubb>
snusnu: that sounds like a good approach
<dkubb>
you can't automate something you don't know how to do manually
<snusnu>
exactly
<snusnu>
dkubb: especially, i need/want to see how it works out with ducktrap in the mix … i need to *see* a few mappers that declare ducktraps "internally", so that i get an idea of the common parts that can be extracted
mkristian_ has quit [Ping timeout: 272 seconds]
mkristian_ has joined #rom-rb
<dkubb>
snusnu: are there other things blocking ROM that you need?
<snusnu>
dkubb: hmm .. lemme think .. i guess there's not really anything that *blocks* atm, as integration will take some time anyway
<snusnu>
dkubb: one thing that will be very awesome to have tho, if not, *essential*, is Relation#join(other, join_definition)
<snusnu>
dkubb: if we don't have that, we will have to track renaming ourselves, like we did with dm-mapper .. which we dubbed "the jersey thing"
<snusnu>
dkubb: i guess it's not that important, as long as we don't have relationship support, and people need to inject specific mappers for their EC/EV needs anyway
<snusnu>
dkubb: but yeah, having that would simplify rom and rom client code, while at the same time opening the door for "nicer" SQL inner joins i'd expect
<dkubb>
I'm not sure what it would buy, it just overloads #join and allows you to do relation.join(other, id: :other_id) instead of relation.rename(id: :other_id).join(other)
<dkubb>
unless there's something I'm missing
<dkubb>
I don't mind changing apis to provide something that is impossible other ways, or saves signficant effort, but it doesn't seem to be the case with this
<snusnu>
dkubb: as soon as we start supporting (or trying to support) relationships, we will have to "track" the renaming that occurred, as we have to rename certain attributes automatically for the joins to line up
kleech has quit [Remote host closed the connection]
<dkubb>
snusnu: why not apply the renaming to the relation so that it returns exactly what is needed?
kleech has joined #rom-rb
<snusnu>
dkubb: granted, i haven't thought about that for a while, and with our new architecture, it might be different .. but i just recalled that this was a major trouble back with dm-mapper .. and i remember that back then, we were talking about pushing that feature down to axiom
<snusnu>
dkubb: that's what we did
<dkubb>
snusnu: that sounds like the best approach, it allows axiom to handle the renaming for you and you just have to map the attributes you get back as-is
<dkubb>
it's more like just doing the renames up-front rather than on the flu
<dkubb>
*fly
<snusnu>
dkubb: hmm, tbh, i can't recall the exact problems right now, so i'd say that i will get back to you with that issue, once i had more time to think it through
<dkubb>
yeah, let's see if it's an issue and come up with a way to solve it together
<snusnu>
yeah, that might be best
<dkubb>
my intention was that when the relationship is declared we could create a relation in the background that includes the rename up-front, and then store an optimized version of it. then there's less mapping at runtime since it was done up-front
<snusnu>
dkubb: one thing that comes to my mind tho, is that without some "hint" as to what attributes to use in a join, generating INNER JOIN statements will be hard?
<snusnu>
dkubb: iirc that's what we did .. and it lead us to having to track every renaming that occured in order to be able to produce proper mappers
<dkubb>
snusnu: I don't think so. I think we can handle that in the sql lib
<dkubb>
or in the axiom -> sql lib
<dkubb>
snusnu: interesting. when you get to the point in ROM lmk, maybe there's something I can do to help
<snusnu>
dkubb: it basically was a "pimped" header, that knew about all renamings that occured
<dkubb>
the renames probably need to be tracked somewhere
<dkubb>
whether it's in ROM or in Axiom
<snusnu>
exactly
<dkubb>
I would suggest we try to push it down to Axiom
<snusnu>
back then we did it in ROM
<snusnu>
right, that's what we said back then too
<dkubb>
let ROM push-down the renames to Axiom so that ROM just takes the relations as-is and maps them 1:1 to the objects
<snusnu>
that'd be ideal, yes
<dkubb>
then it's not so much doing any renaming at all, it's just taking the tuples attributes and setting the corresponding ivars
<snusnu>
iirc, back then it turned out that essentially, the API needed to be pushed down was Relation#join(other, join_definition)
<dkubb>
I suspect this is probably way faster too
<snusnu>
plus supporting code for that, obviouly
<dkubb>
ahh I see
<dkubb>
let's see how far we can go before adding that API change
<snusnu>
yes, fully agreed
<dkubb>
I would prefer for the ROM::Relation api to be as close to Axiom::Relation as possible
<snusnu>
let's not do anything before we're not sure that we need it
<dkubb>
if we need to make the change, then let's do it in Axiom::Relation
<dkubb>
right
<dkubb>
one of the flaws I see with AR and ARel is that the two layers are too different
<dkubb>
you can't drop down from AR and use the same interfaces.. in fact some of the same-named methods do things completely different
<dkubb>
or there are completely differently named methods with different interfaces you need to use
<snusnu>
yeah, we should avoid that at all costs
<snusnu>
it can all work completely identical, with the one difference being, that ROM::Relation will deal with objects, when Axiom::Relation deals with tuples
<dkubb>
I'm all for abstracting things, but AR::Relation isn't really an abstraction. ARel and AR::Relation are both working at the same level of abstraction
<dkubb>
AR::Relation just wraps ARel and changes things so that AR itself needs less internal changes
<dkubb>
I love the ROM::Relation and Axiom::Relation abstraction
<snusnu>
yeah, it feels very right
<snusnu>
now
<snusnu>
didn't with dm-mapper
<snusnu>
that's why we changed it, heh
<dkubb>
yeah, it was the result of listening to the pain
<snusnu>
yup
<dkubb>
I think I need to track our todo list with no granularity than the roadmap page
<dkubb>
I focus so long on one thing that when I come up for air after finishing it, I forget what's next
<snusnu>
heh, i didn't quite get your first sentence tho .. "with no(?) granularity …" ?
<dkubb>
*more
<dkubb>
heh
<snusnu>
heh ok, thought so tbh, but wasn't sure ;) makes sense now
<snusnu>
btw .. i should be able to do sth like this, no?