Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feature Request] Enum Support #166

Closed
aMOPel opened this issue Aug 17, 2022 · 3 comments · Fixed by #187
Closed

[Feature Request] Enum Support #166

aMOPel opened this issue Aug 17, 2022 · 3 comments · Fixed by #187

Comments

@aMOPel
Copy link

aMOPel commented Aug 17, 2022

You've already indirectly talked about enum support in
#34 (comment)

Enums feel like a rather important thing in nim to me, so I think it would great to support it out of the box.

Since Postgres has an enumtype it should be kinda straight forward.

Regarding your question how to handle enums in sqlite:
I have this in my project atm, which encodes enums as strings and parses them back using std/strutils.parseEnum

func dbType*(T: typedesc[enum]): string = "STRING"
func dbValue*(val: enum): DbValue = DbValue(kind: dvkString, s: $val)
func to*(dbVal: DbValue, T: typedesc[enum]): T = parseEnum[T](dbVal.s)

I imagine this could be rather costly for huge databases, so I don't know if it's a great solution.
However the benefit is, that the meaning of the value is preserved in the database.

The alternative would be to encode the enum as ints, obviously. Probably that is the better default choice.
The best way would be, to enable norm users to choose I guess.

Thanks for all the work put into norm. It's great!

@PhilippMDoerner
Copy link
Collaborator

PhilippMDoerner commented Sep 13, 2022

This is not strictly helpful to you since you already stumbled upon how to add enum support, but for others:

There now is norm documentation that details how to add support for whatever data-type you have, including enums.

I'm conflicted on providing a default when this feels like a decision the user might want to specify themselves (not that my opinion matters, I merely wanted to voice it).
If a default must be provided I'd vote for storing as int, with the user having to provide their own dbType/dbValue/to procs if they want something else.

Luckily, as you noted, adding default enum support isn't really difficult, literally just defining these 3 procs once for sqlite and once for postgres and then writing some test-cases for it (which should include a test-case where the default procs get overwritten by user-defined procs for a specific enum, just to make sure that works).

@moigagoo
Copy link
Owner

I agree with the previous comment.

Summary:

  1. Supporting arbitrary types is as easy as implementing three procs.
  2. Norm doesn't have to cover all types there are. Norm covers the obvious types (string is TEXT, int is INTEGER, etc.).
  3. I'm not against adding enum support to the core. PRs are welcome.
  4. If someone chooses to implement this, please store enum values as ints.

@PhilippMDoerner
Copy link
Collaborator

PhilippMDoerner commented Mar 4, 2023

Was implemented in lowdb as part of PhilippMDoerner/lowdb#8 , kudos to ire4ever for doing pretty much all of the work there. Did show me that I should be going over the test-suite there though.

So I just need to release a new lowdb version and norm needs to update its lowdb dependency and we have it here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants