Support for new .Net 4.0 Tuple<T1,T2>?

4 posts, 0 answers
  1. Joseph Lam
    Joseph Lam avatar
    10 posts
    Member since:
    Jan 2010

    Posted 29 Jun 2010 Link to this post

    Any plan to support the new Tuple datatype in .Net 4?

    Thanks

    Joseph
  2. Jan Blessenohl
    Admin
    Jan Blessenohl avatar
    707 posts

    Posted 30 Jun 2010 Link to this post

    Hi Joseph Lam,
    To which backend type do you want to map it? 

    Our problem is that we cannot determine the real type of the tuple. What you can do is to have a Property that exposes the tuple, and inside the property you split the touple and copy it into single fields. We only care about the fields, you can do what you want in the property.

    Sincerely yours,
    Jan Blessenohl
    the Telerik team
    Do you want to have your say when we set our development plans? Do you want to know when a feature you care about is added or when a bug fixed? Explore the Telerik Public Issue Tracking system and vote to affect the priority of the items
  3. DevCraft banner
  4. Joseph Lam
    Joseph Lam avatar
    10 posts
    Member since:
    Jan 2010

    Posted 30 Jun 2010 Link to this post

    Hi Jan

    In our application we have objects holding Tuple arrays like Tuple<string, string>[] and Tuple<int, string>[]. It seems like each of them they should map to a separate table with a foreign key column plus two columns of corresponding types (e.g. string->varchar) . Shouldn't the handling be similar to List<a custom class with two properties>? If the types of T1 and T2 are precisely specified in the code, the ORM should be able to determine the underlying types.

    For objects holding a single Tuple object it's trivial to expose the Tuple in two extra properties as you suggested. But if we have a list or array of Tuples then I think it makes more sense for the ORM to map it to a table.

    Regards,
    Joseph
  5. Jan Blessenohl
    Admin
    Jan Blessenohl avatar
    707 posts

    Posted 30 Jun 2010 Link to this post

    Hi Joseph Lam,
    You are right, the problem is more that we do not have the control over the objects, change tracking and lazy loading will not work, our load and store code that works without any reflection (because of speed) cannot access the internal fields of the tuple.

    What you always can do with such structures that are serializable is to use the [SerializeToBlob] attribute at the field. We are then just serializing the complete content to a blob in the db.

    Regards,
    Jan Blessenohl
    the Telerik team
    Do you want to have your say when we set our development plans? Do you want to know when a feature you care about is added or when a bug fixed? Explore the Telerik Public Issue Tracking system and vote to affect the priority of the items
Back to Top