<snusnu>
dkubb: i've tried to comment it as best as i could at this point, i hope it's pretty self explanatory
<snusnu>
dkubb: i'll be going to sleep in a few minutes, but i'd appreciate any comments as usual ;)
<snusnu>
dkubb: tbh, i like these ideas *a lot* .. seems like this is able to provide nice separation of concerns, full support for multi database setups, while still being reasonably short and concise
<dkubb>
snusnu: hey
<snusnu>
hey dkubb
<dkubb>
snusnu: do you think it should be an error to not define a pk?
<snusnu>
dkubb: yeah, altho this can and should be configured within the adapter providing the block for #setup
<snusnu>
dkubb: it might not make sense for every adapter, i dunno
<snusnu>
dkubb: by block for #setup, i meant the block passed to Database.build
<dkubb>
snusnu: every relation needs a pk. in the absence of an explicit fk, the default is that *all* the attributes form a pk
<dkubb>
snusnu: I dunno about having implicit behaviour though, maybe it would be better to just raise an exception when none is defined. we can always relax it later if we decide to
<snusnu>
dkubb: ah yes, i know that, for a second i meant that you are referring to the database concept of primary key
<dkubb>
yeah, sorry, I'm probably being confusing
<dkubb>
I guess I should rephrase that
<dkubb>
should we require at least one explicit key per relation, or should we rely on an implicit key
<snusnu>
hmm, good question, we might try and see how pure RA works out, and only add the requirement for at least one explicit key later on if needed, it's always easier to add something, than to take it away
<dkubb>
snusnu: also in: foreign_key :order_fk, order_id: orders.id .. do you want to make the fk name optional?
<snusnu>
dkubb: probably yeah, but maybe no, at least it would mean that database propagation rule definitions would need to be "found" via attribute names (that got checked for being FK attributes)
<snusnu>
dkubb: i guess yeah, after all
<snusnu>
dkubb: in general, what i like about this way of constructing things, is that DB specific stuff, is completely separated from the axiom schema, the axiom schema and relation objects know *nothing* about ugly database land, the info to persist the schema is captured in the Database, which supports adapter specific ops
<snusnu>
dkubb: stuff like primary key, unique indices, whatever the backend supports in addition to RA, is completely unknown to the runtime system
<snusnu>
dkubb: same goes for constraint propagation rules, altho i do not know your plans for that (in future axiom)
<dkubb>
I have thought about a DO layer gem that reflects on the current schema state
<dkubb>
if you have a schema that can be reflected you may not even need a DSL to describe it
<snusnu>
yeah heh, i've even started do-schema years ago ;) .. anyways, it will be very easy to construct the "raw" axiom-schema ast from a reflected native schema
<dkubb>
each adapter could return something that can be used with the schema
<snusnu>
all that axiom-schema needs to work, is the ast needed to build up all base relations, and the knowledge which relations belong to which database/adapter, in order to be able to construct gateways .. i guess there's really nothing stopping us from implementing schema reflection
<snusnu>
dkubb: another thing that i like now, is that all the DSL methods are still reasonably simple wrt their (nr of) parameters
<snusnu>
dkubb: this is only possible when splitting it up into these 2 "phases"
<snusnu>
dkubb: otherwise it's just too much info imo, to fit into a few common methods with options
<dkubb>
I'm thinking right now about how much of the Axiom::Database we would actually need up-front, and how much we can get away with not writing
<snusnu>
dkubb: then again, this really isn't the main benefit, the main benefit imo comes from a nice separation of concerns, and well defined places where to implement (adapter specific) extensions
<snusnu>
dkubb: i guess for it to work eventually, we'd need at least the info currently captured in the database DSL
<dkubb>
some of it. I mean, I already have most of the database stuff working and I don't have all of that
<snusnu>
dkubb: and i do not want to mix that into the schema dsl, it's too much, it doesn't belong there
<snusnu>
wdym by you have most of the database stuff working?
<dkubb>
I have an axiom adapter that can be queried, etc. it's not quite as far as the schema stuff of course
<snusnu>
well, that's what axiom-schema is about tho, isn't it .. the schema
<snusnu>
;)
<dkubb>
I do think we need something more to do migrations
<dkubb>
btw, I *have* created something before that builds base relations for every table in a pg database
<dkubb>
it returns a Hash of base relations
<snusnu>
data migrations, yes, schema migrations, yes too, but something different (that's what axiom-schema (Database) is concerned with)
<snusnu>
yeah, i have something like that too
<dkubb>
base relations can represent most of the data at the relation level, what we need is something to represent the list of relations, relationships between them, and constraints between then
<dkubb>
that's where I see axiom-schema sitting
<snusnu>
yeah, you see, current axiom-schema is only providing #[] to access the relatons, it will surely also know about the fk constraints .. that's all we need to build on top of
<snusnu>
but while we're *declaring* the schema, we might just as well collect info to persist the schema, like, auto_migrate
<dkubb>
axiom-schema provides a structure where you can reflect on things
<snusnu>
that's what my stuff is concerned with atm
<snusnu>
and i've tried to separate database specific stuff, from "logical" axiom stuff
<dkubb>
I wonder if we could just reflect on a database and return an axiom-schema for it; then have some algebra operations that can transform it into the schema that we're ultimately going to map to the objects
lfox has quit [Quit: ZZZzzz…]
<dkubb>
I would imagine though, that if something is important at the database level then it's going to be represented in some form in axiom-schema or axiom-relation
<dkubb>
(axiom-relation is what I'll eventually break out the relation specific stuff into)
<snusnu>
dkubb: i guess that would be possible, "but" it's the opposite direction of what my stuff is concerned with atm .. it should be done too of course, eventually
<dkubb>
yeah, I'm just thinking maybe we can get the same end benefit with less objects just by giving the schema a few transformation operations (like renaming tables)
<dkubb>
we'd need those transformation operations for migrations anyway
<dkubb>
s/tables/relations/ ;)
<snusnu>
yeah, that might very well be possible, and i do not want to stop you from thinking about that future at all ;) i'm just concerned with all the database specific stuff we need to collect if we want to define the schema with ruby, and i certainly want to do that ;)
<dkubb>
if a database has a real schema, then it's going to probably be possible to reflect on it and then transform it. if it doesn't have a schema, then we'll need to define an axiom-schema for it anyway and there won't be anything lower level like an Axiom::Database object
<dkubb>
I'm just trying to save you from writing any o the database specific stuff :P
<snusnu>
and for that, is the current Axiom::Database, it might not be the best name even, but that was and is its purpose, supporting backend specific DDL construction
<snusnu>
it has to be done eventually tho ;)
<snusnu>
some way or another
<snusnu>
heh
<dkubb>
hmm, I dunno, it might not be
<dkubb>
you might be able to generate DDL from the axiom-schema objects
<dkubb>
without needing any intermediary
bf4 has joined #rom-rb
<snusnu>
well, at some point, something needs to be declared primary key, needs to be given constraint propagation rules, needs to set unique indices, and of course rename attributes and relations .. while the latter 2 seem very natural to RA, the first 3, well, at least the 1 and 3, aren't RA, and i see no reason to interleave it with that
<snusnu>
also, of course, i'm not saying my current idea is final in any way ;)
<snusnu>
it's just something i like, and believe is very actionable, right now
<dkubb>
primary key isn't part of RA, true
<dkubb>
wdym by constraint propagation rules? chances are if it's to do with constraints it's part of RA
<snusnu>
there's also regular indices, they need to be specified somewhere
<dkubb>
that part is true
<snusnu>
yeah, i guess those are part of RA, i mean stuff like on_delete :cascade
<dkubb>
most RDBMS constraint systems are only subsets of what you can describe in RA
<snusnu>
that, i know
<dkubb>
I believe there are fk constraint/cascade extensions
<dkubb>
but indexes and primary keys are definately not in it
bf4 has quit [Ping timeout: 260 seconds]
<snusnu>
and consequently unique indices i'd assume
<dkubb>
if I drop off suddenly it's because my battery died
<snusnu>
i never know wether they are more like regular indices or more like keys :p
<dkubb>
I'm at 0:03 remaining :)
<snusnu>
hah, i know that .. my battery sucks big time already
<snusnu>
mostly it just powers off without a warning
<dkubb>
unique indexes are part of RA
<dkubb>
but they're not really focused on the index part, more on the constraint side
<snusnu>
what's their difference to keys?
<dkubb>
sorry, same thing
<dkubb>
RDBMS basically takes the concept of keys and automatically indexes them because it's efficient
<snusnu>
so yeah, ra knows keys, and rdbms need to decide between pk and unique indices
<snusnu>
anyways dkubb, before you're off, i should go to sleep finally ;)
<snusnu>
mbj: it's well commented and should be pretty self explanatory, pls get back to me once you've had the time to go through it
breakingthings has joined #rom-rb
<snusnu>
mbj: imo it incorporates everything we've talked about in skype, but shifts more responsibility to what we called #connect (which is now basically Axiom::Database.build followed by an Axiom::Schema.coerce(db_1, db_2, …))
snusnu has quit [Quit: Leaving.]
snusnu has joined #rom-rb
jgaskins has joined #rom-rb
bf4 has joined #rom-rb
snusnu has quit [Quit: Leaving.]
lfox has joined #rom-rb
snusnu has joined #rom-rb
snusnu1 has joined #rom-rb
snusnu has quit [Ping timeout: 260 seconds]
<mbj>
snusnu1: sounds good
snusnu1 has quit [Quit: Leaving.]
snusnu has joined #rom-rb
<mbj>
snusnu: Will look into it later. Still busy.
<snusnu>
mbj: fair enough
vsorlov has joined #rom-rb
<jgaskins>
snusnu: did you want to try pairing again sometime this week or next? :-)
skade has joined #rom-rb
breakingthings has quit []
snusnu has quit [Quit: Leaving.]
snusnu has joined #rom-rb
cored has quit [Ping timeout: 240 seconds]
cored has joined #rom-rb
cored has joined #rom-rb
skade has quit [Quit: Computer has gone to sleep.]
vsorlov has quit [Ping timeout: 240 seconds]
snusnu has quit [Quit: Leaving.]
dkubb has joined #rom-rb
dkubb has quit [Client Quit]
dkubb has joined #rom-rb
vsorlov has joined #rom-rb
kleech has quit [Remote host closed the connection]
kleech has joined #rom-rb
snusnu has joined #rom-rb
kleech has quit [Remote host closed the connection]
Eiam has quit [Quit: ╯°□°）╯︵ǝpouǝǝɹɟ]
kleech has joined #rom-rb
CraigBuchek has quit [Quit: Leaving.]
dkubb|away has joined #rom-rb
dkubb has quit [Ping timeout: 245 seconds]
kleech has quit [Remote host closed the connection]
kleech has joined #rom-rb
bf4 has quit [Ping timeout: 260 seconds]
bf4 has joined #rom-rb
kleech has quit [Remote host closed the connection]