<snusnu>
cored: is this the only task that interests you at the moment? :)
<cored>
snusnu: hehe, I think is a little bit hard
<cored>
I guess you want to talk about devtools, right?
<snusnu>
cored: heh, it definitely sounds like a bit of a larger undertaking ;)
<snusnu>
cored: heh, yeah
<cored>
I have that on the back of my head too
<snusnu>
cored: devtools offers lots of "easy" stuff
<cored>
but I think dm-ambition could be a good addition to the family
<cored>
snusnu: "easy"
<cored>
point me out to them ;-)
<snusnu>
cored: it could, but "unless" used with axiom standalone, it probably wouldn't be widely useful for still a while, well, at least not in Rom
<cored>
I think for ROM could be good enough
<cored>
I'm thinking in repository implementation
<cored>
with same public API for CRUD operations
<snusnu>
cored: the thing is, there are *lots* of things to do for ROM, before it's even close to being able to leverage a "more sophisticated" toplevel RA api
<cored>
I see
<cored>
that's a shame, ROM could change the game ;-)
<snusnu>
cored: tbh, i would love to see something like dm-ambition eventually, but before this will be usable in ROM .. a *lot* of other work has to happen
<cored>
like what?
<snusnu>
cored: it could yes, but it's not just there yet, there's still quite some work ahead
<cored>
I have to read two things to get into more ROM work
<snusnu>
cored: well, there are a few quite fundamental things that are still missing, we need nest/unnest support in axiom to implement embedded collections more easily
<cored>
top level arquitecture desicions and also solnic's article
<snusnu>
cored: dkubb's already working on that
<cored>
that also sounds interesting
<snusnu>
cored: then we also need some sort of PK/FK representation .. which is necessary info for both unit of work and relationships in general
<snusnu>
cored: then there's support for server generated values (especially keys)
<cored>
I thought the unit of work was already done with rom-session
<snusnu>
cored: once those 3 things are in place, there's nothing "foundational" stopping ROM (api) development
<snusnu>
cored: "but" then there's SQL support, quite a few parts are missing there too
<snusnu>
cored: like support for write ops
<snusnu>
cored: and re that PK/FK thing .. axiom needs to be able to accept some kind of "join definition" in its #join api (and friends)
<snusnu>
cored: something where you say, join people and addresses on people.id == addresses.person_id
<snusnu>
cored: this will help both relationship definitions, and nice SQL inner join statement generation
<snusnu>
cored: currently axiom emits natural joins, and while they work correctly, they're kinda hard to read, but that's not the only issue
<snusnu>
cored: if axiom only knows how to perform natural joins, then the burden to track relation/attribute renaming will have to be carried by ROM … and this is stuff is .. hard/ugly
<snusnu>
cored: it's what we dubbed "the jersey thing" in dm-mapper times
<snusnu>
cored: so yeah, i guess that's about it … once those things are in place … rom is really useful
<snusnu>
;)
<snusnu>
cored: now .. wanna know what devtools would benefit from? ;)
<snusnu>
cored: re the unit of work, there's no uow implemented in rom-session currently .. rom-session "simply" tracks state transitions, and yes, it already queues up the ops in memory, in order to flush them on write .. so yeah, one could say an initial implementation of uow is already present
<snusnu>
cored: however, one of the main benefits of having an uow, is that it provides a place to "sort" the queued ops in such a way, that PK/FK dependencies are resolved properly
<snusnu>
cored: so for example, if you try to save a person with associated addresses … it would make sure that first person is saved, and then the person_id FKs in the addresses tuples are properly set to person.id
<snusnu>
cored: and as you might have noticed, for that dependency resolution, we need the PK/FK representations too
<snusnu>
cored: to give you a greater picture, we're thinking of modelling PK/FK constraints "within" the schema definition .. so a ROM::Schema will know about its PK and FK constraints, which then basically form the foundation for relationships
<snusnu>
cored: also, they should be modeled in such a way, that it's easy to generate DDL from them too .. so that something like dm-constraints can take them, and serialize them to the backend too
<snusnu>
cored: so PK/FK are actually a couple of specific constraint objects … and there will eventually be others .. like e.g. we eventually want to generate CHECK constraints from the type constraints represented in Axiom::Types