jgaskins has quit [Quit: This computer has gone to sleep]
bf4 has quit [Ping timeout: 272 seconds]
CraigBuchek has joined #rom-rb
CraigBuchek has quit [Ping timeout: 252 seconds]
snusnu has quit [Quit: Leaving.]
bf4 has joined #rom-rb
bf4 has quit [Ping timeout: 252 seconds]
CraigBuchek has joined #rom-rb
CraigBuchek has quit [Ping timeout: 264 seconds]
bf4 has joined #rom-rb
bf4 has quit [Ping timeout: 272 seconds]
<dkubb>
snusnu: postmodern: I think I prefer the symmetry of the attribute keyword first, then have key be separate
<dkubb>
I also *strongly* oppose making an explicit primary key related keyword. a primary key is not special compared to another key, like say a natural key. this dsl would make it seem special and that works against some of my intentions
CraigBuchek has joined #rom-rb
<dkubb>
it's similar to the difference between a base relation and a view. a view shouldn't be thought of as so different from a base relation, and in a properly implemented system there would be no outward distinguishing behaviour between the two
<dkubb>
sure, the relation or database may have metadata to say what it is, but you shouldn't be able to tell via just using it
<dkubb>
a key, any key, behaves exactly the same. we need a small annotation to resolve the arbitrary distinction in RDBMS based DBs, but it's a mistake to promote it to something super special just because RDBMS implemented a broken version of the relational model and decided to extend things by making primary keys
CraigBuchek has quit [Ping timeout: 245 seconds]
<dkubb>
unique indexes and primary keys are the same in the RM. a key should be the only things that can be joined to by another table's foreign key. every relation as an implicit key containing every attribute in the header; along with explicit keys that may further restrict the relation.
<dkubb>
my intention with the DSL is that it given the differences between the real RM and the RDBMS model, that it favour the first when there is conflict. the former is simple and well developed and consistent while the latter is inconsistent, and implemented differently in each vendor's system
<dkubb>
snusnu: hopefully you see this in the logs :)
<dkubb>
I would much prefer having `key :attr1, :attr2` and `key :attr1, :attr2, primary: true`.. with the latter a simple annotation, but one that brings less attention to the key and doesn't hint that it is somehow different from any other key
<dkubb>
snusnu: yeah, I like that.. for the relation stuff, is the name "customers" or "people" ? that's a bit unclear to me
<dkubb>
snusnu: I feel like the first position should be the name of the thing, while the options should describe the original/base name
<snusnu>
dkubb: that's exactly how i imagine it
<dkubb>
ahh ok, so this is customers and addresses relations
<snusnu>
dkubb: so the relation is named :people in the backend
<dkubb>
oh I see
<snusnu>
yeah
<snusnu>
it goes inline with the :name option for the attribute :zip
<snusnu>
in objectland it's called :zip, and :zipcode in the backend
<dkubb>
yeah, I think the option name shoudl be the same for both
<dkubb>
I feel like there coule be a better name than :name, but I can't think of it
<snusnu>
you'll also notice that the FK definition refers to people.id, not customers.id
<snusnu>
yeah, me neither
<dkubb>
oh I see
<snusnu>
i guess that's fine?
<dkubb>
do you think that'll be confusing?
<snusnu>
no idea ;)
<snusnu>
i don't see it to be less confusing if it were customers.id tho
<dkubb>
did you decide to go after implicit attributes for foreign keys?
<snusnu>
yes
<snusnu>
the foreign_key definition should "install" an attribute too
<snusnu>
no need to define it twice, nor give it a type
<dkubb>
I dunno if customers.id or people.id would be less confusing. it's hard because on one side you want to define the mapping in one place and then refer to the same name everywhere, but you also have to map to the original schema
<dkubb>
in this specific case you *could* define an attribute named customer_id, and define it's name as person_id .. then your foreign key defintiion would be: foreign_key customer_id: customer.id
<dkubb>
I would think attribute renaming is the only case where it might make sense to define an explicit attribute for a foreign key
<snusnu>
i agree
<snusnu>
that could be allowed, otoh, i don't see a real point in renaming an FK
<snusnu>
ideally, those are lost in object land anyway
<snusnu>
dkubb: but i need to leave now, will bbl, i'll read the logs …
snusnu has quit [Quit: Leaving.]
skade has joined #rom-rb
<dkubb>
it's hard to know if you should design for object-land first, and then map it to the database, or database primarily and have mappings for the object stuff
skade has quit [Quit: Computer has gone to sleep.]
skade has joined #rom-rb
skade has quit [Client Quit]
CraigBuchek has quit [Quit: Leaving.]
lfox has quit [Quit: ZZZzzz…]
CraigBuchek has joined #rom-rb
lfox has joined #rom-rb
cored has joined #rom-rb
cored has joined #rom-rb
mkristian has quit [Quit: bye]
cored has quit [Ping timeout: 272 seconds]
cored has joined #rom-rb
postmodern has joined #rom-rb
vsorlov has quit [Ping timeout: 245 seconds]
mbj has joined #rom-rb
mbj_ has joined #rom-rb
mbj has quit [Ping timeout: 272 seconds]
mbj_ has quit [Ping timeout: 272 seconds]
mbj has joined #rom-rb
mbj has quit [Ping timeout: 246 seconds]
<postmodern>
where are the IRC logs hosted?
<postmodern>
irclog.whitequark.org is down
mbj has joined #rom-rb
cored has quit [Ping timeout: 252 seconds]
cored has joined #rom-rb
<mbj>
hi all
<mbj>
dkubb: hi
cored has quit [Ping timeout: 272 seconds]
cored has joined #rom-rb
cored has quit [Changing host]
cored has joined #rom-rb
cored has quit [Ping timeout: 245 seconds]
lgierth has joined #rom-rb
<dkubb>
mbj: hi
<dkubb>
postmodern: it looks up now. that's where we host the logger. although I've been thinking we should create irclog.rom-rb.org at some point
CraigBuchek1 has joined #rom-rb
cored has joined #rom-rb
cored has joined #rom-rb
CraigBuchek has quit [Ping timeout: 252 seconds]
cored has quit [Ping timeout: 240 seconds]
cored has joined #rom-rb
jgaskins has quit [Quit: This computer has gone to sleep]
cored has quit [Ping timeout: 272 seconds]
cored has joined #rom-rb
cored has joined #rom-rb
mbj has quit [Ping timeout: 272 seconds]
cored has quit [Ping timeout: 252 seconds]
breakingthings has quit []
cored has joined #rom-rb
cored has quit [Ping timeout: 246 seconds]
cored has joined #rom-rb
mbj has joined #rom-rb
jgaskins has joined #rom-rb
<mbj>
dkubb: I read the backlog where you and postmodern talked to snusnu about the AST as DSL <=> OO layer IR.
<mbj>
postmodern: The main reason for proposing this is the ability to have a non 1:1 mapping between DSL and OO layer.
<mbj>
postmodern: I dont think the overall complexity will be increased. We'll just have smaller more SRP conforming parts.
<postmodern>
mbj, plus we are simply using the DSL to build up the Axiom Relation objects
<mbj>
postmodern: yeah, also we can reorder ops in the ast.
<mbj>
postmodern: This way we can create FKs after relations are created. No need for an explicit finalization phase.
<mbj>
postmodern: Just defending snusnu here a bit ;) Not that you both attacked him.
<mbj>
snusnu and me had this ideas, and for now I really like them. Morpher (ducktrap 2.0) uses ast transforms to simplify AST <=> OO layer.
<mbj>
For example a really complex node composition in ducktrap is represented as a single node in the AST. Than the AST gets transformed into the more "primitive" nodes that are behind this DSL action.
<postmodern>
mbj, you can also do the re-ordering in the DSL
<mbj>
sure I could do this explicitly in another custom build DSL.
<mbj>
But IMHO DSL code should not know about all this details.
<postmodern>
mbj, the DSL is just a set of methods that accept data, and store them in an internal representation
<mbj>
I'd rather like to generate the DSL at some point ;)
<mbj>
Because implementing DSLs over and over scares me.