Details

    • Type: Improvement Improvement
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Fix Version/s: 1.0.7, 1.1.0
    • Component/s: None
    • Labels:
      None

      Description

      Currently, DynamicCompositeType is a super dangerous type. We cannot leave it that way or people will get hurt.

      Let's recall that DynamicCompositeType allows composite column names without any limitation on what each component type can be. It was added to basically allow to use different rows of the same column family to each store a different index. So for instance you would have:

      index1: {
        "bar":24 -> someval
        "bar":42 -> someval
        "foo":12 -> someval
        ...
      }
      index2: {
        0:uuid1:3.2 -> someval
        1:uuid2:2.2 -> someval
        ...
      }
      ....
      

      where index1, index2, ... are rows.
      So each row have columns whose names have similar structure (so they can be compared), but between rows the structure can be different (we neve compare two columns from two different rows).

      But the problem is the following: what happens if in the index1 row above, you insert a column whose name is 0:uuid1 ? There is no really meaningful way to compare "bar":24 and 0:uuid1. The current implementation of DynamicCompositeType, when confronted with this, says that it is a user error and throw a MarshalException.
      The problem with that is that the exception is not throw at insert time, and it cannot be because of the dynamic nature of the comparator. But that means that if you do insert the wrong column in the wrong row, you end up corrupting a sstable.

      It is too dangerous a behavior. And it's probably made worst by the fact that some people probably think that DynamicCompositeType should be superior to CompositeType since you know, it's dynamic.

      One solution to that problem could be to decide of some random (but predictable) order between two incomparable component. For example we could design that IntType < LongType < StringType ...

      Note that even if we do that, I would suggest renaming the DynamicCompositeType to something that suggest that CompositeType is always preferable to DynamicCompositeType unless you're really doing very advanced stuffs.

      Opinions?

        Activity

        Aleksey Yeschenko made changes -
        Component/s Core [ 12312978 ]
        Gavin made changes -
        Workflow patch-available, re-open possible [ 12749346 ] reopen-resolved, no closed status, patch-avail, testing [ 12756953 ]
        Gavin made changes -
        Workflow no-reopen-closed, patch-avail [ 12645763 ] patch-available, re-open possible [ 12749346 ]
        Sylvain Lebresne made changes -
        Fix Version/s 1.0.7 [ 12319244 ]
        Sylvain Lebresne made changes -
        Status Open [ 1 ] Resolved [ 5 ]
        Assignee Sylvain Lebresne [ slebresne ]
        Reviewer edanuff
        Fix Version/s 1.1 [ 12317615 ]
        Resolution Fixed [ 1 ]
        Sylvain Lebresne made changes -
        Sylvain Lebresne made changes -
        Attachment 0001-allow-comparing-different-types.patch [ 12509052 ]
        Sylvain Lebresne made changes -
        Field Original Value New Value
        Attachment 0001-allow-comparing-different-types.patch [ 12509052 ]
        Sylvain Lebresne created issue -

          People

          • Assignee:
            Sylvain Lebresne
            Reporter:
            Sylvain Lebresne
            Reviewer:
            Ed Anuff
          • Votes:
            0 Vote for this issue
            Watchers:
            6 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development