<snusnu>
solnic: it also fits nicely with mbj's mapper
<solnic>
snusnu: what's important to me now - do you agree with rom-relation + rom-mapper + rom-session = rom
<solnic>
rom-relation would have our relation graph
<solnic>
rom-mapper the mapping part
mbj has joined #rom-rb
<solnic>
I can't imagine working more on stuff where I need to worry about both relation and mapping concerns
<snusnu>
solnic: hmm, i think we need all 3, but maybe, just maybe, the relation graph should be something different from rom-relation? it's really just a quick thought
<solnic>
snusnu: you mean having a different name?
<solnic>
rom-relation kinda fits with our class scheme
<solnic>
s/scheme/hierarchy/
<snusnu>
solnic: i wonder if the relation graph should be a "simple" data structure that consists of rom-relation relations
<solnic>
yes
<solnic>
that's exactly what I'm thinking about...
<mbj>
haha, I could not resist
<solnic>
just the graph, raw db access
<snusnu>
yes of course it would be like that :) .. so i wonder if that datastructure might deserve to be a separate project .. but as i said, i'm not sure
ptico has quit [Remote host closed the connection]
mbj has quit [Client Quit]
<solnic>
snusnu: I think it makes sense to have it as a separate project because it's A HUGE THING and provide standalone functionality
ptico has joined #rom-rb
<solnic>
s/provide/provides/
<solnic>
snusnu: it's basically data store access without mapping
<solnic>
you get raw tuples back
<solnic>
that's it
<solnic>
it's what we wanted to have anyway, it's just that we'd mixed this layer with mapping layer a lot
<solnic>
that's why it was so hard to implement
<snusnu>
solnic: we're not on the same page i guess, i'm wondering if there should be rom-relation *and*, say, rom-schema (being the graph) .. otoh, this would leave rom-relation to be nothing more than a simple wrapper on top of axiom relations, with injectable mappers … that might be a good thing, or it may be too fine grained
<solnic>
and trully finish
<solnic>
I'd say - let's start with rom-relation and see how it evolves
<solnic>
we'll see if it makes sense to keep it separate as a fourth piece
<snusnu>
yeah, i fully agree, we need to split out the mapper and make it injectable into our enhanced relations
<snusnu>
agreed
<solnic>
sweet
mbj has joined #rom-rb
<snusnu>
so, another "administrative" question, obviously we want to be talking in this new channel, but how do we communicate that to #datamapper lurkers? #datamapper will be pretty much dead soonish i think
<snusnu>
which makes me think: how does the ROM rename relate to dm1? i mean, shouldn't we make some announcement to that end too?
<solnic>
snusnu: I dunno, I could send another random tweet and maybe it'll be RTed million times like last time :P
<snusnu>
hah
<solnic>
snusnu: srsly though, yes we should
<snusnu>
or, we could at least set a new channel topic in #datamapper, "redirecting" users over here
<solnic>
we should post to DM1 ML imho
<snusnu>
yup, that too
<solnic>
I also want to publish some info on my blog
<snusnu>
you should do that
<solnic>
esp that we're looking for corpo sponsors
_whitelogger has joined #rom-rb
<mbj>
there he is!
<solnic>
good ;)
<solnic>
ok live updates - loving it
<mbj>
yeah
whitequark has joined #rom-rb
<whitequark>
mbj: note that freenode policy requires channel topic to notify participants that the channel is publicly logged.
<mbj>
whitequark: Good point!
<snusnu>
whitequark: thx for hooking us up! and yes, we need to do that!
<mbj>
solnic: You registred the channel, can you set a title as we have in #datmaapper?
<mbj>
solnic: I'm formself a total IRC looser
<solnic>
mbj: yes gimme a sec
<whitequark>
re migration from #datamapper
<whitequark>
just add it to the topic there.
<snusnu>
yeah, i think we need to wait for dkubb to do that tho
<solnic>
snusnu: ok so I suggest renaming rom to rom-relation
<solnic>
and add rom-mapper
<solnic>
and extract mapper stuff from rom-relation
<solnic>
and focus on rom-relation for now
<mbj>
I'll stay in channel, but cannot participate on discussion.
<solnic>
mbj: loldude
<solnic>
mbj: it doesn't work like that ya know? :D
<mbj>
hehehe
<mbj>
I dont have desktop notifications for irc
<mbj>
So it depends on discipline
<solnic>
it's like saying "oh I'm gonna go to a pub with my buddies and just sit and stare how they drink beer"
<solnic>
mbj: ok, ain't gonna ping you then, ttyl
<solnic>
snusnu: one thing bugs me though - your awesome join strategy thing, where does it belong? :/ it uses info from attribute sets...and relationship sets...
<solnic>
snusnu: oh and btw "rom" gem would be a meta gem depending on relation/mapper/session gems
<solnic>
so it's a bit like data_mapper gem (much smaller though)
<solnic>
s/it's/it'd/
<snusnu>
solnic: yeah, i like that split
<snusnu>
solnic: re the join strategy, imo it should/could be pushed down to axiom(-sql-generator)
<solnic>
snusnu: that's what I was hoping to hear :D
<solnic>
we'll push a few more things to axiom I suspect...
<snusnu>
solnic: the problematic parts, or rather, those parts i haven't yet figured out exactly, is how to make it possible to "use" mapped names (i.e. names the app uses), while still propagate down to the names the backend uses
<namelessjon>
In the readme examples, should env.build(*, :postgres) be env.build(*, :default) or does it magically infer :postgres from 'postgres://...' which seems sketchy.
<snusnu>
namelessjon: in my app, i use :default
<snusnu>
namelessjon: i realize you probably just want to try it out, but imo that api is going to change anyway
<solnic>
snusnu: rite. by saying "bugs me" I actually meant exactly that part
<namelessjon>
snusnu: All the readme examples do { :default => 'postgres://...' } but then define mappers on :postgres ...
<snusnu>
solnic: i'm not surprised
<snusnu>
namelessjon: that sounds like a readme bug then :)
<solnic>
snusnu: but...we only need fk names to join relations
<solnic>
so we only have to have relations knowing about join key names
<solnic>
and mapper doesn't have to know those are fks
<solnic>
it just maps it to whatever you want it to map to
<solnic>
do we need mappers to know about fks?
<solnic>
heck, to we need mappers to know about associations?
<solnic>
like you load stuff from the db via a join, that's a concern on the relation level
<solnic>
once you get tuples back you send it to the mapper
<solnic>
and it's configured to map them correctly
<mbj>
Cant you just stop with all these interesting discussions :P
<solnic>
mbj: no
<solnic>
:D
<mbj>
:D
<snusnu>
solnic: imo mappers needn't know about relationships
<mbj>
I have to log out, but now e have a LOGGER
<mbj>
cu later
mbj has left #rom-rb [#rom-rb]
<solnic>
snusnu: my gut feels tells the same
<solnic>
lolmbj ;)
<snusnu>
solnic: they should just receive a (nested) tuple and map it
<solnic>
totally
<solnic>
wdyt about "joined mappers"?
<snusnu>
sounds "easy" on the tuple level
<solnic>
I'm starting to think it was a bad idea
<snusnu>
joined mappers being mappers for joined relations?
<solnic>
yes
<solnic>
a mapper could just load stuff depending on what's inside the tuple
<snusnu>
i don't see how they make a difference, it happens to be a joined relation, and you will have to inject a proper mapper for that
<solnic>
hmm rite
<snusnu>
a mapper should only ever work on the tuple level (of course, a touple can be *nested* which means it can contain a collection (relation) of other tuples below some "key"
<solnic>
snusnu: btw with injected mappers we basically need to drop the idea of a mapper instance wrapping a relation
<solnic>
and have JUST relation
<snusnu>
right
<solnic>
question is how/where do we inject a mapper instance
mbj has joined #rom-rb
<solnic>
should the relation be composed of an axiom relation and a mapper
<solnic>
lolmbj again
<snusnu>
i think so
<mbj>
Guess what, I found myself reading irclogger....
<snusnu>
lol
<solnic>
haha
<solnic>
that's too funny
<mbj>
Need my wife standing next to me pointing me to clients repos...
<solnic>
I know a professional term for that you know :)
<snusnu>
imo it could be ROM::Relation#initialize(axiom_relation, mapper)
<solnic>
starts with an A ;)
<mbj>
haha
<solnic>
snusnu: yeah me thinks the same
<mbj>
I'll blacklist irclog.white... via etc hosts. finally cu guys.
mbj has quit [Quit: leaving]
<solnic>
haha
<snusnu>
any bets on when he's going to join again?
<snusnu>
lol
<solnic>
in 3
<solnic>
2
<solnic>
1
<solnic>
oh hai mbj?
<solnic>
;)
<snusnu>
hehe
<solnic>
snusnu: anyhow
<solnic>
snusnu: when joining...do we build special joined mappers on the fly
<solnic>
or stick to building them up-front
<solnic>
and just accessing them through registry
<solnic>
?
<snusnu>
imo if we can (and i think we can), we should do it upfront
<solnic>
rite
<solnic>
would be nice
<snusnu>
i'd also love to have an immutable environment
<solnic>
snusnu: speaking of which
<solnic>
it bugs me that relations have access to environment
<solnic>
but I can't figure out how to avoid that
<snusnu>
remind me why they have it now please
<snusnu>
because of relationships?
<solnic>
joining
<solnic>
yes
<snusnu>
yeah
<solnic>
in other words - relationships
<solnic>
we could maybe have something higher level for joins
<solnic>
so that relations would only expose interface to work on a single axiom relation
<snusnu>
it really feels like it should be possible to have join information in simple compositions of other info
<solnic>
and something higher-level that gives you access to all relations
<solnic>
that thing is environment actually
<snusnu>
yeah
<snusnu>
and right now, the env already encapsulates the relatio graph, no?
<solnic>
yes
<solnic>
and mapper registry
<snusnu>
yeah
<solnic>
having relations knowing about env is bad
<solnic>
design
<snusnu>
full ack
<solnic>
so basically what we're talking about here
<solnic>
is to have something that makes this: env[User].join(env[Order]) shorter :)
<solnic>
snusnu: wait...maybe repository should be that thing...?
<solnic>
so basically env[User] would return user repository
<snusnu>
currently iirc repository knows about all registered relations keyed by their name
<solnic>
see
<solnic>
if it knew about mappers we'd be all set
<solnic>
not sure if it's a good place
<snusnu>
me neither
<snusnu>
i only had a quick look at repository code lately, because the in memory one actually isn't working
<solnic>
meh
<solnic>
repo isn't a good place
<solnic>
because repo is per relation
<solnic>
we need something like a database access object
<solnic>
env groups all repos and mappers
<solnic>
so maybe env
<snusnu>
that database access object you mentioned, wouldn't that be the graph
<snusnu>
?
<solnic>
env[User].groups <= this would require some proxy object
<solnic>
shit. rite
<solnic>
the graph
<snusnu>
it knows about all relations, and not only base relations, but *all* relations
<solnic>
it doesn't know about the mappers though :)
<solnic>
that's the thing, once you join you need to get a mapper
<snusnu>
at some point i was also thinking, if we should maybe turn the whole thing upside down, like only define relations (either base or "virtual" ones) .. provide a dedicated mapper for every relation, and yeah
<snusnu>
like, if we can support that, we can *then* think how to construct parts of it automatically
<solnic>
rite
<solnic>
so screw joins for now?
<snusnu>
might be an option
<solnic>
I guess things will clarify on their own once we have the nice separation done
<snusnu>
if we focus on creating relations (base or joined), and allowing to inject mappers into them, we bascially have everything we need .. the rest is sugar
<snusnu>
imo the key to easy working with joined relations is to be able to specify some sort of Reference objects
<snusnu>
so, if a relation has a reference to another, that's basically an FK definition
<solnic>
well we need to be able to support ad-hoc joining
<snusnu>
yeah, we definitely need that too
<solnic>
like you just want to build a complex stuff and have it loaded by some mapper
<solnic>
stuff as in relation :)
<snusnu>
but once we can inject mappers into *any* kind of relation, and we add meta info like FK references, we should be all set for more automatic construction of joined relations, using a dsl or whatever
<snusnu>
yeah
<solnic>
hmm ritre
<solnic>
rite even
<solnic>
yeah man, let's take a step back and get shit working w/o joins and relationships
<solnic>
once that part is clean and done
ptico has quit [Remote host closed the connection]
<solnic>
it'll be much easier to continue working on relationships
<snusnu>
yeah, something like ROM::Relation.new(complex_join_of_some_axiom_relations, specifc_mapper_for_that_shit)
ptico has joined #rom-rb
<solnic>
it'll be DEAD SIMPLE to do btw :P
<snusnu>
yeah
<solnic>
the only thing which is hard is relationships
<snusnu>
and they're only sugar
<solnic>
totally
<solnic>
ok ok
<snusnu>
i have a feeling that if we end up with clean objects that can be easily constructed upfront, *i* might not even need any nice dsl on top of it
<solnic>
that is very likely to happen :)
<solnic>
ok, I'm gonna do rom=>rom-relation then
<snusnu>
in my mind, it's like, if i think of relationships more as *views*, it's equally simple
ptico has quit [Remote host closed the connection]
<snusnu>
and makes explicit construction feel even more right
<solnic>
yeah
<solnic>
snusnu: I will cut a branch for future reference
<solnic>
as I'm gonna do some code nuking buddy
<snusnu>
so yeah, once we can construct *any* kind of relation, and support injecting a mapper that knows how to handle that exact relation, we're all set for more
<solnic>
and it will be a great great starting point
<snusnu>
nice
<solnic>
snusnu: btw - gh with auto-redirects == awesome
<snusnu>
hah yeah
<solnic>
pulling from old location still works
<solnic>
so cool
<snusnu>
solnic: it'd be seriously awesome if axiom were to support #group sooner than later
<solnic>
snusnu: it's on dan's plate
<solnic>
snusnu: he wants to build SQL generator now
<solnic>
and then improve some stuff in axiom, like grouping :)
<snusnu>
sweet
<solnic>
snusnu: once I'm done I'll push 0.0.2
<snusnu>
solnic: is what we currently have actually pushed to rubygems as 0.0.1?
<solnic>
snusnu: no
<solnic>
snusnu: it's a blank gem
<snusnu>
ok
<solnic>
snusnu: dkubb forgot to set 0.0.0
ptico has joined #rom-rb
<solnic>
snusnu: it's kinda sweet that mappers could be anything
<solnic>
snusnu: it gives you a lot of flexibility
<solnic>
anyhow, dinner time, ttyl
<snusnu>
ok ttyl
ptico has quit [Remote host closed the connection]
<snusnu>
solnic: imo we could import mbj's mapper into rom-mapper and start from there
<solnic>
snusnu: we could
<snusnu>
solnic: maybe it assumes too much already tho
<snusnu>
solnic: like, it's already integrated with session, which might or might not be a good thing
<solnic>
true
<snusnu>
btw, wdyt about the use of concord throughout rom code? i'd vote for it
<snusnu>
it saves locs and it communicates a specific kind of object
<solnic>
snusnu: ok
<solnic>
snusnu: I thought about it
<solnic>
it's cool
<snusnu>
awesome
<solnic>
I think I'll vote for collapsing those TINY libs into a single one though
<solnic>
but that's ok
<snusnu>
that might be an option eventually, but imo it's still too early to do it