-
|
Title should explain the question. I ran into multiple people having issues with this in the last couple of days. Maybe we havent caught all differences but the one me and the community saw were related to enums. Basically in postgres we generate and drop enum types. in sqlite we just have text (or int). Both end up mapping to actual rust enums.
I mentioned it here #836 im sadly not familiar with SeaORM at all so i hacked something together. So is this behavior expected or do we want to change this? |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 5 replies
-
|
I believe for the extent this is possible we would always want compatibility. Which may mean in this case to find a way to abstract enums and not use a native type. That said, this direction is holding a line of “performance is good enough” but we should be able to let people use native types when they need, since almost always it will be the better option (people will rarely switch database providers after they went to production). in other words if it is easy we should go for it but remember that mostly it is a development convenience. On most cases people will just use Postgres in production and be OK with native types. |
Beta Was this translation helpful? Give feedback.
-
|
Totally agree! But i think we should make sure that at least the examples have migrations that work with both. Makes it easier to test things. |
Beta Was this translation helpful? Give feedback.
-
|
It should also be clear that the classic "Sqlite for local, postgres for prod" is not as it sounds. By using sqlite locally you will end up losing native features on production currently |
Beta Was this translation helpful? Give feedback.
-
|
Correct. Fixing up the demo in example is something we should do — right just removing the roles implementation is what we considered in order to keep it simple but still be a kitchen sink kind of thing. |
Beta Was this translation helpful? Give feedback.
-
|
Thats nice. Im just trying to document some issues me (and others) get confused about while learning how the entire code base works. Hopefully i can move to committing more discussing less soon! |
Beta Was this translation helpful? Give feedback.
-
|
Thanks 🙏 |
Beta Was this translation helpful? Give feedback.
I believe for the extent this is possible we would always want compatibility. Which may mean in this case to find a way to abstract enums and not use a native type.
That said, this direction is holding a line of “performance is good enough” but we should be able to let people use native types when they need, since almost always it will be the better option (people will rarely switch database providers after they went to production).
in other words if it is easy we should go for it but remember that mostly it is a development convenience. On most cases people will just use Postgres in production and be OK with native types.