<snusnu>
mbj, dkubb: how would you guys suggest i tackle the virtual relations in axiom schema?
<snusnu>
it seems to me that initially, i should just store and not evaluate the blocks, process the base relations, and only then evaluate the virtual relations
<mbj>
snusnu: virtual = !base_relation ?
<mbj>
snusnu: Just to "sync" your understanding
<snusnu>
yes
<snusnu>
i settled on that for a lack of a better name
<mbj>
snusnu: For my understanding, why we need to deal with non base relations in axiom-schema?
<snusnu>
mbj: to put it bluntly, for the same reasons we also create views and not only tables in rdbms
<mbj>
snusnu: jo, your strategy from above is IMHO solid.
<snusnu>
mbj: there's no other way i can think of right now … the nicest api to construct these relations, is the api that proper axiom relations expose .. so they need to be built at this stage .. eventually, it might be possible that "calling" this api would create ASTs too, so processing could then be implemented differently?
<dkubb>
you could track dependencies between the relations and use a tsort, but it'll probably be easier to just do two passes
<dkubb>
I would save the tsort for later on if you find some other thing that can't be done without evaluating relations in a specific order
mbj_ has joined #rom-rb
mbj has quit [Read error: Connection reset by peer]
<dkubb>
snusnu: most of the relational model docs/books just refer to it as a view, but I have seen the term virtual relation.. although usually more as an example.. like they'll say: "A view is kind of like a virtual relation, it is indistinguishable from a base relation except it is not actually physically stored anywhere"
<dkubb>
snusnu: although, I just thought of one scenario where you may need to evaluate based on dependencies..
<dkubb>
snusnu: you can evaluate base relations in one pass, but views may be derived from other views
<snusnu>
dkubb: good point yes, i've thought about that too already
<snusnu>
dkubb: re virtual relations vs. views .. should we settle on the term virtual relations maybe? (when talking here, and later on in docs)
<snusnu>
dkubb: i actually like views, but i fear that given the nature of applications these days, views is too overloaded a term
<dkubb>
snusnu: lemme check some more docs to see what is common. I'd rather stay closer to what the RM community uses because it's better for people to do further research, as opposed to coming up with our own terms for things
<dkubb>
snusnu: we've already gone with RM terms over SQL with "group"
<dkubb>
the problem with SQL based RDBMS systems is that they created a bastardized/neutered subset of RM and called it relational
<snusnu>
dkubb: i see your point, but i already see the confusion about which kind of view one means, in the context of a typical application .. that of course only applies if views is the RM community accepted term
bf4 has joined #rom-rb
<snusnu>
dkubb: then again, the same problem probably already exists anyway
<dkubb>
snusnu: ideally the user shouldn't need to care too much what is and is not a view, other than when designing the schema
<snusnu>
dkubb: i do realize that, i'm mostly thinking about future situations where i tell my colleague about this view i added, and he will ask me if the css is already there too
<dkubb>
snusnu: if we can make the differences tiny or non-existent, then it gives people lots of flexibility when changing the schema too.. you can alter some relation, then define views to look like the original relation and existing code should continue to work
<dkubb>
hehe
<snusnu>
;)
<dkubb>
I wasn't even thinking about view in the MVC sense
<snusnu>
the thought came to my head when i envisioned docs
<snusnu>
and general talking about the areas you typically have in an app
<snusnu>
but as i said, the same problem already applies, it's just that i know no real ruby api that exposes "sql" views
<dkubb>
yeah, ok, maybe we should go with "virtual relation" for now. we can always change it later. when we describe it anywhere in the docs, we should say something like "it's similar to a view in an RDBMS, except it is usually writable, which is often not the case in most SQL based RDBMS"
<snusnu>
yeah
<dkubb>
I implemented the writable logic as closedly as I could to the theory. I'm curious to see how it works in practice
<dkubb>
I was surprised by how many operations could be made writable. and I wondered then why it's not more common.. it certainly wasn't super difficult
bf4 has quit [Ping timeout: 272 seconds]
<dkubb>
you just need to define the rules of how the data flows through the tree of operations, and which operations cannot propagate the write
<snusnu>
yeah, i can't wait .. i guess that in a lot of situations, it will simply be "hidden", and by that i mean, that anyone fully expects that when you save a person with a newly added task, both will be saved .. the difference (to me) mostly seems to be that one isn't yet used to *declare* such relations explicitly upgront
<snusnu>
dkubb: another way, would be to consistently use the term *base* relations when it applies, and simply say relations to everything else
<snusnu>
i guess i'd like that even more
<dkubb>
yeah, I prefer that
<dkubb>
we can use relations everywhere, and only use base relations where it makes a difference.. like when talking about how something will be persisted on disk
<snusnu>
yeah
<dkubb>
I think one of the reasons that views in RDBMS-land aren't more capable is that they're seen as *so different* from normal tables
<dkubb>
people don't demand that they act the same
<dkubb>
I think they would if everyone only talked about tables, and used the term base table when talking about persistence
mbj_ is now known as mbj
<snusnu>
yeah, i wonder how the rom approach might be able to "change" that .. i guess a lot of people are just very used to writing ad hoc queries throughout their code, that's probably simply because the rdbms don't support views good enough
<snusnu>
the shift with rom that i can imagine, is that it'd be much more common to think of the "queries" upfront, define them in the schema, and end up with much less ad hoc queries
<dkubb>
I don't mind if people also define adhoc queries, I just think it's nicer if we give them a way of defining them up-front and naming them
<dkubb>
I mean, you really shouldn't be literring your controllers and views with custom query logic
<snusnu>
exactly, both should be possible and used when it makes sense
<dkubb>
you're better off putting that in a class and refering to it by name
<snusnu>
yeah
jgaskins has joined #rom-rb
<snusnu>
dkubb, mbj: does anyone of you know about an object that responds to everything and then returns an array of the "path" that was invoked? say: foo.bar.baz would return [:foo, :bar, :baz]
<snusnu>
i guess i need one of those for a nice FK definition syntax
<snusnu>
hey jgaskins! dude, i'm so sorry, you were right, i totally forgot :/
<dkubb>
snusnu: I supposed you could make one if you inherit from BasicObject, and have your method_missing create a new version of the object with the method used appended to some list
<jgaskins>
snusnu: hehe No worries, man. I meant to check back with you the day before and forgot. :-)
<dkubb>
def method_missing(*args, &block) self.class.new(@path.dup << [args, block]) end
<snusnu>
dkubb: i'd allow to define an FK like this with such a thing:
<snusnu>
foreign_key person_id: people.id,
<snusnu>
task_id: tasks.id
<dkubb>
since you probably want to "carry-along" all the data passed into the method
<snusnu>
i need no data passed in
<snusnu>
oh, i guess i misunderstood you
<dkubb>
I was just saying what you would do for a generic one. if all you care about is the method name, then you could further slim it down
<snusnu>
or not, i really don't need any args or blocks, i only need a record of all method names that got called
<snusnu>
yeah
<dkubb>
yeah, maybe start off with something specific to your needs and see if you need it for anything else
<snusnu>
yup
<dkubb>
better to start off with a specialized object and genericize it later
<snusnu>
that's actually a fun little task, i'm gonna do that now
<dkubb>
I like this approach because if I try to pass in arguments to the method ruby itself blows up
<dkubb>
I don't have to write anything specific to do it
<snusnu>
dkubb: i like that
<snusnu>
(and "secretly" wish that you'd indent the private keyword ;)
<dkubb>
haha
<snusnu>
:p
<dkubb>
I used to
<dkubb>
but I prefer outdenting it now. it helps me visually break up the public and private parts better
<dkubb>
I can scan with my eye and see it, rather than it getting lost in the noise
<snusnu>
i used to do that too .. then i changed, and nowadays my old style (your current one) looks very awkward to me .. i know mbj does it too
<jgaskins>
vim-ruby indents it so i usually leave it, but i tend to think it's like rescue. if you def/rescue/end, you outdent the rescue. i just don't care enough to try to go against the grain.
<dkubb>
it sticks out so well it's almost like drawing a horizontal line between the two parts of the code
<dkubb>
yeah
<dkubb>
i think if people indented rescue in a method it'd be weird
<dkubb>
I assume it's valid syntax, but I've never tried
<jgaskins>
yeah, i can't imagine it'd be invalid, and i'd probably be confused if it were.
<dkubb>
it wouldn't be ruby-ish. it's incredible forgiving with syntax, probably in many cases to it's detriment
<dkubb>
I secretly kind of wish for a whitespace sigificant mode :P
<jgaskins>
hehe, not a fan of end/end/end/end/end?
<dkubb>
snusnu: just define an #each and make it Enumerable
<dkubb>
snusnu: oh wait, I guess that will add a ton of other methods, some of which may conflict with the relation names
<snusnu>
yeah i guess so
<dkubb>
snusnu: to_a should never conflict with a relation name
<snusnu>
oh, i left the * in method_missing args, need to remove that
<dkubb>
snusnu: you like using * in method_missing there?
<snusnu>
yeah
<dkubb>
ahh right
<snusnu>
no
<jgaskins>
yeah, i was just going to say, if you call foo.bar.select.baz, that'd be rough
<snusnu>
heh
<snusnu>
dkubb: actually, while i see the reasoning behind removing the * .. isn't that a bit "offensive" too? i mean, it does change #method_missing signature .. then again, it can be argued that that's the whole point
<jgaskins>
snusnu: i like the idea of using to_a (maybe even to_ary if implicit coercion would be useful) over path or chain. not sure why i didn't think of that.
<dkubb>
jgaskins: it's not the end problem.. I'm just kind of anal retentive about my code formatting, and if the code would fail to compile without precise alignment that would make be happy
<snusnu>
jgaskins: yeah, it seems the most natural api name for that, the whole point is turning it into an array .. well, actually, splatting it into a sexp eventually
<dkubb>
I can't remember if splatting calls to_a or to_ary (or both?)
<jgaskins>
to_ary, i'm pretty sure
<snusnu>
good point, altho i was fully prepared to do *path.to_a .. but *path is surely nicer
<dkubb>
the less surface area of the Path object you expose in the API the better
<snusnu>
right
<jgaskins>
i agree with that, but to_* methods are generally used for conversion, so i wouldn't imagine there'd be much collision with anything supplied by the user.
<jgaskins>
obviously, i might very well be wrong, but that's my knee-jerk reaction
<dkubb>
heh, I just did basically the same thing here to test it
<jgaskins>
lol
<snusnu>
i just need to return such a Path object from a method_missing in DSL::Relation::Base .. and then splat the instance into a sexp
bf4 has joined #rom-rb
bf4 has quit [Ping timeout: 272 seconds]
<snusnu>
dkubb: hmm, thinking a bit more about it, i guess it'd be even "safer" if i had an object that would allow me to call exactly one method and then return a basic object that knows the path, but has no further method_missing hook
<snusnu>
i guess we actually don't want to allow chains of arbitrary length .. we need a relation name and an attribute name
<dkubb>
snusnu: you only need to chain one hop away?
<snusnu>
heh yeah
<snusnu>
i guess so at least
<snusnu>
or can you think of usecases where we might need more?
<snusnu>
this whole thing is to help with defining foreign keys in axiom schema
<dkubb>
snusnu: not atm. you need a named relation to chain stuff
<snusnu>
i want to be able to do
<snusnu>
foreign_key person_id: people.id
<dkubb>
snusnu: so I can't imagine you needing to do more than that. you can even probably have two classes, one to represent a relation, and one to represent a relation + attribute
<snusnu>
and construct s(:fk_constraints, s(:reference, :person_id, :people, :id)) from that
<snusnu>
in fact, i only need to construct the "inner" reference
snusnu has quit [Quit: Leaving.]
snusnu has joined #rom-rb
<dkubb>
yeah, I prefer having the least-capable objects for internal components of a system
bf4 has joined #rom-rb
<dkubb>
snusnu: are you thinking about providing inferred types for foreign keys?
<dkubb>
for example, in your addresses relation you explicitly declare person_id to be Integer, then you do: foreign_key :person_id, people.id .. you could infer the person_id type and constraints from the people id attribute
<dkubb>
snusnu: in DM1 we *almost* got it perfectly right. there were still a few things that required you to define an explicit FK, but we didn't know about those things before doing it.. I feel like it would be possible to do perfectly if we wanted to