ktorm
ktorm copied to clipboard
kotlin-orm
Creating tables?
Is there any support for creating tables from a Ktorm schema? Or do tables have to be manually created using direct SQL commands?
There is no support for creating tables from a Ktorm schema. I know that @vincentlauvlwj wanted to write an IDE plugin that would help you in creating tables but I don't know the status of it. With some help from @vincentlauvlwj, I ended up writing my own 'migration library' for a web framework that I'm working on.
As @ashokgelal said, there was no support for creating tables from a Ktorm schema. I'm planning to write an IDE plugin for that but it's still a plan now...
@ashokgelal Seems you have finished your migration library. Can you share your code? Maybe that will inspire me to some extent.
Well, it's still in early alpha state but the framework repo is here: https://github.com/ashokgelal/alpas
There is no README only because I'm spending all my energy writing the documentation: https://alpas.dev/docs
The migration/database/Ktorm related code is here: https://github.com/alpas/alpas/tree/master/framework/src/main/kotlin/dev/alpas/ozone
Comes from Exposed by Jetbrains... it's tight-compose between user's entity and Exposed entity is really tiring to deal with, you even cant create a mock instance of your entity. i guess this is derived from the avoid of using reflection or-so.
i've noticed that ktorm has a very similar descriptive syntax, comparing to exposed. it's looks very nice, thank you for developing such a good framework :wink:
i've also noticed seems there's nothing equivalent to ShemaUtils.createNonExisitingTables in exposed which will automatically create/alter table structure based on the table instance you provide, it's very convenient, for you'll liberate from managing the consistent between your database-initialization sql and ktorm descriptive syntax. i'll say maybe this is the last mile of ktorm.
maybe off-topic: is there any way to specify size for columns like varchar? exposed's syntax provide two parameters, as varchar("column name", <size>) while ktorm only has the former, which is really wierd, IMHO.
BTW the translate in exposed, maybe equivalent to your ColumnRegisteration mechanism, but hugely consiser, and easier to use. I think it's worth take a look at. i'll try to port this mechanism into ktorm, hope works well.
Edit: sorry. now I know the missing size is because the auto-creation of tables is not handled by ktorm... but if it's gonna be implemented - deeply hope so, i'll investigate at this as well - it's necessary for creation to work.
@Ray-Eldath for setting the column size, you can start here: https://github.com/alpas/alpas/blob/master/framework/src/main/kotlin/dev/alpas/ozone/MigratingTable.kt
Since, I've already started allowing migration of a database, very similar to what you have mentioned, I'm more than willing to collaborate on this. If you want to chat further, I'm available on Slack here. Feel free to join and ping me (Vincent is also available there in case we need him to clarify something).
What's the state of this enhancement? I'm new to Ktorm & can't see anywhere in the docs how i can create tables using the DSL.
Is it not possible to create tables using ktorm? I am used to calls like .createTableIfNotExist()
@vincentlauvlwj Is there a plan to realize this function? like hibernate can auto create/update tables when entity change, golang gorm also support, it can be seen that it is a very useful function. we have to give up ktorm without this, because our product must support remote upgrade for many customers.
Unfortunately, creating tables is only part of the picture. Over time, the overall schema will change. Sometimes operations will be as simple as renaming columns, but other times more complex schema or even data migrations might need to happen like adding a table for a new model, extracting data from an existing model into the new tables and then removing columns from the old tables. This in itself is a completely different set of challenges from the ORM itself and although a straightforward integration with a tool like that would be highly advantageous, it's understandable if the ktorm team doesn't jump onto it. I'd personally suggest looking into Flyway or Liquibase for schema maintenance and leave ktorm to do object-relational mapping.
Would be great if there was some tool that could take the Ktorm entity definitions and generate a Liquibase changelog file. So we don't have to manually create those. Just a thought.
How about adding a method to check that the connected database schema is compatible with the ktorm definition? Then we could use Flyway for migrations and run the check in CI/staging to catch mistakes.
How about adding a method to check that the connected database schema is compatible with the ktorm definition? Then we could use Flyway for migrations and run the check in CI/staging to catch mistakes.
That is a very good idea. I wish I had the time to look at implementing this, would be very useful.
