Closed MDeltaX closed 6 years ago
It is possible to use nested relations with Tupleable
but not with the generically-derived instance. The issue is that generics don't provide sufficient type information to marshal a RelationAtom
back-and-forth.
However, you can easily hardcode the type information yourself into the Tupleable
instance- just implement toTuple
, fromTuple
, and toAttributes
.
Historical note: the original Tupleable
instance did contain sufficient type information to marshal RelationAtom
s, but the additional type information made it a burden on all other types, so I removed it.
Let me know if an example would be helpful. It would probably be useful to others, as well.
An example would be great, you could extend docs/tupleable.markdown with it.
Can't I instead implement Atomable [Comment]
and use generics for Tupleable Blog
and Tupleable Comment
?
@koenigmaximilian , please take a look at the new example.
Let me know if you have any questions.
@agentm Thank you!
hi @agentm I am looking generic ways to make nested relations too.
Historical note: the original Tupleable instance did contain sufficient type information to marshal RelationAtoms, but the additional type information made it a burden on all other types, so I removed it.
What if typeclass Atomable turns a record type (whose fields have selector names) into a RelationAtom. In this way, typeclass Tupleable will generically turn a record field with Atomable typeclass into a RelationAtom.
It's intuitive to me since a type whose fields with selector names kind of matches a relation with attribute names. ConstructedAtom seems lose some information about selector names.
I would like to hear some opinion of yours. What do you think about this idea? Is it reasonable to make it default/generic?
What I can think of is ... one of (very odd) case is when two record types makes each other its own field. In this way there will be infinite RelationAtoms. So do ConstructedAtoms. But it seems still worth to generically model nested relations from Haskell types.
I think I wasn't thinking it through.
A RelationAtom is a Relation that can has many tuples. However, a field of record type can only be a relation with only one tuple. A RelationAtom is more like a field of a list of record type in haskell rather than a field of record type. An Atom is more like a sum type. And a Relation is more like a product type. RelationAtom seems used in group senario.
I guess I'll go with the custom Tupleable example.
Indeed, the nesting is tricky to represent generically. There are a few options:
Tupleable
for RelationAtoms (with a default of no support)NestedTupleable
instance which looks like the old one but supports nestingNone of the options are particularly appealing, which I why I simply chose to force users to implement their own Tupleable
instance for this unusual case.
Please let me know if you gain any further insight into how this could be represented better.
Thanks for the advice! After further thinking, I come to this conclusion.
My scenario is storing DbRecord a
of project-m36-typed in project-m36.
It saves additional information about a haskell value/ a m36 tuple
.
I can:
Nested relations seems more like statistics report, which needs aggregation operation, afterwards. So I think, too, it is not necessary to implement a haskell value
-to-nested relation
internally.
Is it possible to model nested relations with Haskell types? I've tried
but
[Comment]
andSet Comment
are converted toConstructedAtom
instead ofRelationAtom
.