The ORM Foundation

Get the facts!

Custom data types mapped to unary fact types

Last post Tue, Nov 29 2011 23:19 by Matthew Curland. 1 replies.
Page 1 of 1 (2 items)
Sort Posts: Previous Next
  • Fri, Nov 25 2011 23:25

    Custom data types mapped to unary fact types


    When mapping a unary fact type to a relational view, a column is created with a logical True/False data type. When this model is exported to Oracle a column with NCHAR(1) is created.

    I prefer to use numeric data types in Oracle for boolean values, 0 for false and 1 for true, so in the relational view I tried to assign a numeric data type to this column, such as an unsigned integer, and set the ValueRange of the role to {0,1}. However, it wasn't possible because after reloading the model the unary fact type is converted into a binary fact type, which is obviously not desirable.

    I thought it would be a good idea to at least comment this here.

    Jose Carlos

    Filed under:
  • Tue, Nov 29 2011 23:19 In reply to

    Re: Custom data types mapped to unary fact types

    Hi Jose,

    Interesting scenario. Unary fact types are currently stored in a binarized form which is revalidated on load. If the form doesn't match (including the required boolean data type) then the unary-ness of the fact type is abandoned and you get a binary fact type with a missing role player, as you see.

    Relational columns do not have their own data types. The dropdown shown is simply smoke-and-mirrors on the data type corresponding to the underlying value types. 

    There are three things that could happen here:

    1. Changing the data type of an implicit boolean value (the right-hand-role in a binarized unary fact type) could throw except during reload, where you see the current behavior. This is somewhat tricky because there are legitimate reasons to modify the fact type, such as when inserting a role.
    2. You get the same behavior as on reload (the fact type 'binarizes'). This is ugly because the fact type will now be missing a role player and have errors, which will remove the relational column.
    3. The data type for a boolean should be read-only in the relational view. This should be done regardless of 1 or 2, and--given that this is the only way for the user to change the underlying data type--would completely hide any other issues.

    For now, I'll look at making this read-only for a column selection. 

    As for getting a different data type, look for NCHAR(1) in PROGRAMFILES\Common Files\Neumount\DIL\Transforms\DDILtoOracle.xslt and change it to something else. This simple fix won't get the value range, but is closer to what you want.


Page 1 of 1 (2 items)
© 2008-2019 The ORM Foundation: A UK not-for-profit organisation -------------- Terms of Service