Enums support in annotation processors

[geralt-encore]

What are your thoughts on this feature? Would be happy to implement it.

[nikitin-da]

It would be great!
But how can we perform serialization? Should it be some db value extractor or just ordinal value? (danger for persistence in case when we will add new item in the middle ordinal will be shifted) =(

[geralt-encore]

You are right about ordinal. But what about valueOf? Then we can just save String representation of enum.

[nikitin-da]

Oh yeah, with name - valueOf it should work! 👍

[artem-zinnatullin]

But proguard, if it'll rename enum values users can get very "funny" problems since proguard does not guarantee that after code changes it'll give same names. We'll have to be very careful with documentation and samples. But other than that I'm 100% for doing that!

…

On 8 Dec 2016 11:43 am, "Dmitrii Nikitin" ***@***.***> wrote: Oh yeah, with name - valueOf it should work! 👍 — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#730 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA7B3F-NcWBZsMjACTpsiL4H8n4f2_TPks5rF8MfgaJpZM4LHgSr> .

[geralt-encore]

Wow, thanks, @artem-zinnatullin, for a really good point! I haven't thought about it.
So looks like that we have to options and both of them aren't perfect. Using ordinal can cause potential issues with changing order of enum members. And using valueOf can cause issues with Proguard and additional headache for users because of it. What will be the best option you think? Or maybe I missed something?

[artem-zinnatullin]

Another thing I'm worried about is that users might want to change value type and names stored in the db, let's say I have enum(VALUE1, VALUE2) but I want to store them as integers 1 and 2 no matter what ordinal() they have or names, especially useful in case if you rename value in enum but want to keep compatibility with already stored values in database. I guess we'll need to add annotations support for that, maybe reuse existing one.

…

On Sun, Dec 11, 2016, 17:23 Ilya Zorin ***@***.***> wrote: Wow, thanks, @artem-zinnatullin <https://github.com/artem-zinnatullin>, for a really good point! I haven't thought about it. So looks like that we have to options and both of them aren't perfect. Using ordinal can cause potential issues with changing order of enum members. And using valueOf can cause issues with Proguard and additional headache for users because of it. What will be the best option you think? Or maybe I missed something? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#730 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA7B3Hy_rVexzcx5qWDkEDfFvymLcBLLks5rHAdlgaJpZM4LHgSr> .

[RickBoyerDev]

From experience with other ORM's, I wouldn't use either the ordinal or name, instead I implemented an "id" for each enum and persisting the id.

[geralt-encore]

SQLDelight uses just valueOf for mapping enums.

[RickBoyerDev]

Yeah, that's actually how I persisted my enums before as well. Then when I was working with greenDAO, I came across this:

How to convert Enums correctly
Enums are popular with data objects like entities. When persisting enums, there are a couple of best practices:
Do not persist the enum’s ordinal or name:
http://greenrobot.org/greendao/documentation/custom-types/

The biggest problem I see is if Proguard obfuscates the enum names, so I switched to implementing custom IDs.

[artem-zinnatullin]

The biggest problem I see is if Proguard obfuscates the enum names

You are in control of that