added enum support

[cdraf]

Added an enum converter that creates a text column in the db.

Added Enum type support so query syntax (select/filter/where) can be used and a unittest (test_enum.py) that demonstrates each.

To support Enum in python 2.7 and 3.3 I've changed setup.py to conditionally add a dependency on pypi enum34.

[Martmists-GH]

Enums should also support ints and floats since those can be used too, so it would be recommended to add dynamic support for those.

[luckydonald]

His enums in unit tests are using integers, so they get stored as string and converted back afterwards?

class Result(Enum):
     SUCCESS = 0
     FAILURE = 1
     UNKNOWN = 2

Would it store SUCCESS or 0 in that text field?

[luckydonald]

I actually was hoping something like

class Language(Enum):
  EN = 0
  DE = 1
  ES = 4

would result in something like:

DROP TABLE IF EXISTS Language;
CRATE TABLE Language
  id INTEGER PRIMARY KEY,
  value TEXT NOT NULL
;
INSERT INTO Language (
  id, value
) VALUES (
  (0, 'EN'),
  (1, 'DE'),
  (4, 'ES')
);

[cdraf]

I apologize for the delayed response.

@Martmists all data types should be supported since the Enum name is what gets stored in the db.

@luckydonald it will store the Enum name SUCCESS. Storing the name is not as efficient as storing the value in cases where the value (ex: 1) takes up less space than the name (ex: SUCCESS) but this way will support pretty much any Enum value. I don't know if this is the direction pony wants to go.

Another thing to consider is that some dbs support enumerations which may be a better way to represent the data. This is not something that these changes support.

@luckydonald your Language example is how it will look in the db.

[luckydonald]

@cdraf I added a ES key to my example above to make my intensions about mapping the values more clear.

But, now that I think about it, enums are all about storing some arbitrary value behind an textual key.
This makes sense, not to include the value into the database as that also could change later.
From how I understand it now however you'll using an incremental integer key instead?

[peteretep]

is there any chance this will be merged? I'm looking for an orm with simple enum support.

[luckydonald]

@cdraf
But will it create the table Language, so that other tables would reference it?#

class Language(Enum):
  EN = 0
  DE = 1
  ES = 4

becomming

DROP TABLE IF EXISTS Language;
CRATE TABLE Language
  id INTEGER PRIMARY KEY,
  value TEXT NOT NULL
;
INSERT INTO Language (
  id, value
) VALUES (
  (0, 'EN'),
  (1, 'DE'),
  (4, 'ES')
);

and

class SomeTable(db.Entity):
  id = Autoinclement()
  lang = Required(Language)

becomes

CRATE TABLE SomeTable
  id INTEGER PRIMARY KEY,
  lang INTEGER NOT NULL REFERENCES Language.id
;

So will it have a table for the enum, and reference that one?

[andgein]

Hi, @kozlovsky! Is there any chance this will be merged or supported by Pony ORM directly soon?

[half2me]

also looking forward to this

[luckydonald]

I made a simpler approach (#502) which will make the database actually store the value, and not as proposed here, the key of the enum.

This should allow the same usage from a python side, but makes the handling of the values in the database trivial, as an IntEnum they can be handled as int everywhere, and it doesn't changes the type of queries.

Also the table column definition would directly correspond to the definition in the table, making upgrading from a normal field to a Enum based field easy as well.
For the above example of a language key that definition could now be even improved:

lang = Required(Language, length=2)

[jason-johnson]

Can this be modified to use native database enum support where available (e.g. postgres)?