Enum Support

[elicwhite]

We need to make sure that there is support for enum's and sets when defining entity structure.

Something like the following may work:

public $readonly = array("type" => "enum", "values" => array(0,1));

This issue is copied from https://github.com/actridge/Spot/issues/1

[elicwhite]

History:

TheSavior: Maybe this could even be extended to give support for a "bool" keyword that would just be an enum enforced to 0 and 1? This might be too specific though.

vlucas: I like this idea, especially when paired with validation to ensure a correct value. I might name the field type "select" though, since we are already using other HTML5 input types like "email", "tel", etc.

TheSavior: select would be good for enum, although, there should be something simple for booleans. Either a "bool" or "bit". Sql Server (Microsoft) uses "bit" for anything that can have a value of 0,1, or null.

http://msdn.microsoft.com/en-us/library/ms177603.aspx

vlucas: There is already a "boolean" field type.

Specific driver implementations will use whatever they need to in order to implement the functionality most efficiently. MySQL uses TINYINT(1), and SQL Server could use "bit". The only important detail is that the values on the actual entity are always either true, false, or null (no value).

[asattler]

Hi there, is there any progress to this feature request?

[pnomolos]

If enum support doesn't have to be native then something like this could fairly easily be added using the existing type system like this:

'colours' => array('type' => 'enum', 'fields' => array('red', 'green', 'blue'))

and internally the value could be stored as the integer index of the field.

@vlucas Thoughts?

[vlucas]

I was actually thinking something very similar, only I kind of want to use select as the field type and options as the array of possible options to be more in-line with HTML field names that already exist (especially considering I have already started this trend in the code with email, tel, uri, etc.).

'status' => array('type' => 'select', 'options' => array('published', 'draft', 'deleted'))

Native enum support would store the value of the selected type, like "published", but I would really like support for just storing the key, so you could even use an explicitly defined array:

'status' => array(
    'type' => 'select',
    'options' => array(
        'published' => 'Published (Publicly Visible)',
        'draft' => 'Draft (Not Publicly Visible)',
        'deleted' => 'Deleted'
    )
)

Spot would store the value if the array is numerically-indexed, and use the key if its an associative array. Maybe there would also be an option to force Spot to store the index even if the database type supports enum directly. Maybe something like native_enum (true/false).

This would allow you to populate dropdowns and expose the options in your API in a much easier and more straightforward way. Validation on the type (via the type system) would also have to check to ensure the set value is one of the options in the array (or the key if the option is set).

I would love further discussion and/or thoughts/feedback on this topic.

[elicwhite]

My immediate feeling is that we would want database integrity to be handled as much as possible by the database. A big issue with trying to do this completely natively is that some dbms don't support enums. However I think I can be convinced on handling it in Spot since the issues with trying to be native are large and not very user friendly.

I don't know if I agree about putting the nice pretty directly in a Spot Entity. That seems like something that should be in the application level logic. I feel like the database is for storing data, and the ORM is designed for easy access to that data, not for formatting that data in a way that it is necessarily ready to be printed to the user.

[vlucas]

Maybe the answer is to just dodge it for now. I can go ahead and add a select type that is handled 100% in Spot for all adapters, and perhaps later we can add a proper enum type that is database native for the drivers that support it if there is still demand for that (my feeling is that there won't be).