Support for ENUM on class schema [moved]

[lvca]

This is Issue 62 moved from a Google Code project.
Added by 2010-07-14T08:57:51.000Z by l.garu...@gmail.com.
Please review that bug for more context and additional comments, but update this bug.

Original labels: Type-Enhancement, Priority-Low, v2.0

Original description

OrientDB already supports Java ENUM, but it would be great if the developer could define a set of enumerations at schema level.

Example:

OClass account = db.getMetadata().getSchema().createClass( "Account" );
account.createProperty("name", OType.STRING);
account.createProperty("status", OType.ENUM, new Object[]{ "active", "suspended", "deleted" } );

[mattaylor]

+1

[srgg]

It would be nice to have this

[PhantomYdn]

Guys,
Are you going really have this in 2.1 (Feb 2)?

Let me mention: that "enums" might be of different nature: strings, integers, doubles and etc. So from my point of view: that's not an separate OType but rather constrain on a property.

Please: lets try to come up with final design. In case of "no go" decision of OrientDB: that will be done on application level in Orienteer.

[lvca]

2.1 is too early. By the way @PhantomYdn do you have any design proposal?

[mattaylor]

We already implement this by using a 'Constrainded' mixin which has a beforeCreate and beforeUpdate hook. These hooks will lookup 'constraint' records which have a  the following properties - 'className', 'fieldName', 'enums', 'default', and my be extended further as necessary. When a record is created on a class which extends 'Constrained' the beforeCreate hook will lookup all 'constraint' records where className matches the created class and for each contraint record, when an enum list is defined the corresponding property of the new record is validated against it and if a default value is defined then this is used if the field is absent in the new record. Similar logic would apply beforeUpdate, and exceptions thrown as expected.

In an ideal world however these 'enum' and 'default' values should be defined or extended from an 'OProperty' class and we should be able to reference these from hooks via a Traits/mixin mechanism for multiple inheritance, so we can apply custom logic for validation, referential integrity checks, implement bidirectional links accross classes etc.

-- 
Mat Taylor
Sent with Airmail

On January 28, 2015 at 10:55:57 AM, Luca Garulli (notifications@github.com) wrote:

2.1 is too early. By the way @PhantomYdn do you have any design proposal?

—
Reply to this email directly or view it on GitHub.

[PhantomYdn]

From OrientDB perspective, I'm thinking about somethink like that:

OClass account = db.getMetadata().getSchema().createClass("Account");
account.createProperty("name", OType.STRING);
account.createProperty("type", OType.STRING).addConstraint(new EnumValidator("ACTIVE", "INACTIVE"));
account.createProperty("id", OType.INTEGER).addConstraint(new RangeValidator(0, null)); //long version of .setMin and ,setMax
account.createProperty("inventory", OType.LINK).addContraint(new MyCustomValidator());

But following methods should be available:

public <T extends OConstraint> T getConstraint(Class<T> constraintClass);
public OProperty addConstraint(OConstraint... cons);
public boolean removeConstraint(OConstraint cons);
public boolean removeConstraint(Class<? extends OConstraint> cons);

setMax, setMin, setPattern and etc. methods should be shortcats for adding some particular constraint. To be consistent following method might be added as shortcut for ENUM constraint:

public OProperty setAllowedValues(Object... values);
public Collection<T> getAllowedValues();

[PhantomYdn]

I can take a lead and try to implement this if you are OK. But there is a dependency with following issue:
#3429

@lvca Could you please help, btw, with pushing that issue really into 2.1?

[mattaylor]

A critical requirement from my perspective is that enums, defaults and other constraints must be configurable via SQL and not just from java. (e.g using an OProperty or OConstraint class or via custom property attributes)

[lvca]

@PhantomYdn I like your proposal. Release 2.1 will be pretty short, I'm not sure we can implement it. I could spend a couple of hours to see if it's that easy moving hooks before validation. What about SQL commands to manipulate ENUMs?

[PhantomYdn]

@lvca Please check that... From my point of view it's really a huge design gap... I can try to fix that as well, but I will definetly need someone from your team to check and validate everything...

Regarding syntax. I guess we might use oracle notation for that. Example:

ALTER CLASS ClassA
ADD CONSTRAINT MyConstrain CHECK ([property] condition) [DISABLE];
or
ALTER PROPERTY MyProperty
ADD CONSTRAINT MyConstrain CHECK (condition) [DISABLE];

-- examples of condition statement
min 0
max 10
enum ACTIVE, DISABLED
range 10 100
custom my.custom.package.MyConstraint arg1 arg2

[mattaylor]

untill we have a more generic solution for mixins / traits on classes and/or management of hook execution order, why not just ..

alter property myClass.myProp enums a,b,c,d

[Eric24]

+1