search

dkubb / axiom

Simplifies querying of structured data using relational algebra
https://github.com/dkubb/axiom
MIT License
459 stars 22 forks source link

add spec that tests joins against different Tuple classes #32

Closed ahamid closed 11 years ago

ahamid commented 11 years ago

this just illustrates some behavior I ran into a long time ago which is probably as-designed. in any case leaving a spec here in case this case is not already covered or you have other comments regarding the equivalence of different Tuple classes.

dkubb commented 11 years ago

@ahamid this is a really interesting use case. Were you often joining tuples of different types?

Let's say this did work, what would be the behaviour? It has two classes involved in the join, one on the left and one on the right.. which would it choose to use to instantiate the new tuple with?

Maybe it would use the most "specific" of the two, which would imply one is an ancestor of the other? So it would use TupleSubclass in your example. (This actually seems reasonable to me)

That leads me to another line of thought about siblings though, eg:

class SiblingTupleOne < Axiom::Tuple; end
class SiblingTupleTwo < Axiom::Tuple; end

... they both share the same ancestor, but I think it would be weird to use Axiom::Tuple since they both could have special behaviour/information that you'd be throwing away with the common class. I'm guessing this should raise an exception, but feel free to let me know if you think it should.

I think the behaviour this spec outlines, specifically how it returns 0 rows is the worst possible thing I could be doing. I don't like it when a system silently fails. I'd much rather an exception is thrown if incompatible tuples are used; however it turns out that we define compatibility or incompatibility.

ahamid commented 11 years ago

This is related to my earlier attempt to specialize Tuple in order to expose some back end information (then when copies/conversions happen, the two types end up getting compared somewhere). Honestly I don't know how this could ever work, and it's probably algebraically nonsensical to have heterogenous tuples (maybe a way to override the Axiom Tuple implementation globally would work, but that's tantamount to monkey patching anyway). Given I don't really have this use case any longer, an exception, or even just a note in the Tuple rdocs would suffice. It could be annoying to implement a check every single place Tuples are copied/converted/compared.

dkubb commented 11 years ago

@ahamid yeah, I agree. I would probably want to keep using Axiom::Tuple objects internally until we have multiple requests for this.

For now I'll close this but if it comes up against I'll reference this issue for some of the discussion points I brought up.

ahamid commented 11 years ago

Another thought: if the case ever arises again, a single opaque user-settable Object reference in Tuple ("@user_data" or "@tag"?) might go a long way to support referencing external data, and should be easily propagated (at the expense of one more pointer slot per tuple).