add Features in Tupleable: Two Records in one relation

[YuMingLiao]

Hi @agentm , I would like to ask your opinion about a feature I want to add.

I want to turn a haskell record type into a Relation while adding an record for Uniqueness Constraint. But I don't want to add the field in Haskell type. It will force me to hide some fields when using yesod-form.

What if I add a Generic Tupleable case that is ( RecordTypeA, RecordTypeB ) and turn it into one Relation with {fieldA1,FieldA2...,FieldB1, FieldB2,...)?

In that way, I can turn a tuple back into a value (RecordTypeA, RecordTypeB). And get crud operation easily since fields in RecordTypeA can be set as Uniqueness Constraint.

Does that make sense for you?

About details: (RecordType,RecordType) = Attributes are both type's fields combined. ( , ) = Two attributes. RecordType in a tuple will be turned into a ConstructedAtom type.

[YuMingLiao]

Oops. I guess I think too much. A Custom Tupleable will suffice.

class A a where
  funA :: a -> Bool

instance A Int where
  funA = const True

instance (A a, A b) => A (a,b) where
  funA = const True

[agentm]

I think that this should be completely doable with a custom Tupleable instance.

This use-case reminds me of views. If you could point the yesod model to a projection view of the full relation, then you wouldn't need to go through these hoops.

[YuMingLiao]

Oh, you are right! That's a more essential aspect: a projection view. How about view update in project-m36? I've read about #233

Both view updates and isomorphic schemas are examples of bidirectional transformations.

So is it better that there is a bidirectional transformation of UpdateExpr and DeleteExpr between a projected view and the full relation?

Or I guess I can just update the original full relation.

[YuMingLiao]

I guess I need to re-read Isomorphic Schemas first.

[YuMingLiao]

So is my case related to the implementation of project/extend isomorphisms?

[agentm]

The potential for isomorphic schemas to solve your problem is there, but isomorphic schemas in Project:M36 do not (yet?) support projection slices because certain uniqueness constraints are required to be in place for the isomorphism to hold and I didn't implement the detection for the constraints.

I regard isomorphic schemas as an experimental feature because I haven't figured out precisely which use-cases they can best serve, but they make more mathematical sense than views.

Sorry- it looks like a custom Tupleable instance is your best option. Alternatively, you could consider adding a feature to the Tupleable typeclass which adds a projection (and sets some defaults for new tuples).

[YuMingLiao]

I am always attracted by that mathematical sense and so get distracted. I can't help but thinking a type-level RelationType operation check.

I think, to hold a uniqueness constraint in a projected view, one have to provide extra fields that fits the original relvar's constraint when insert and update, and when delete make sure the user agree on dropping the fields that are not in the view.

Thanks for explanation and advice!

[agentm]

Yes, I get stuck on the math as well. I remind myself, however, that there are plenty of databases that have run off into the weeds based on some perceived premature optimization. Project:M36 strives to be different, even if that means some commonly expected functionality can never be implemented due to logical conflicts.