[Feature Request] Auto Models Migration about surrealdb.go HOT 5 CLOSED

Hey, thank you for opening this feature request and opening the pull request! Really nice functionality.
Personally I think the drivers should be streamlined only for database access and protocol functionality.
Since this change is a quality-of-life feature, it may be better if it belonged in a separate repository.
If we merge this functionality into this repository, it means we need to main it's functionality and development long-term and potentially provide feature-parity with other drivers (which there could be many of).
@tobiemh what do you think?

from surrealdb.go.

It can be really useful for ORM-like usage.

it means we need to main it's functionality and development long-term and potentially provide feature-parity with other drivers

I agree but still, if it will be in the main repo it will be better maintained for a long time.
like, SurrelDB has aim for become the ultimate cloud database
ORM-like AutoMigrate will be on that list to become one.

For my personal preferences, I will use automigrate.
like Gorm, etc. ORM libs, mostly all of them have AutoMigrate
such a comparison bun doesn't have AutoMigrate and most people are waiting for a long time, one of them is me.

On the other hand, I understand not all people may want an ORM-like system in their database driver.
still, if will be added it will impact big and it will be easier to use schemafull tables

from surrealdb.go.

@phughk

If we merge this functionality into this repository, it means we need to main it's functionality and development long-term and potentially provide feature-parity with other drivers (which there could be many of).

I think it depends on the language, the community, and the database engine itself, how it should behave, not every language provides the same way of doing things, and a major version can break everything.

Of course, all things can be done in any language but how much that will cost and gain? It is always a tradeoff.
Even, not every community is active like others.

So, I think to resolve these conflicts, I suggest using versioning to our advantage with SurrealDB.go for example, with the current version of SurrealDB v1.*, the SurrealDB.go has an AutoMigration which is a community-added feature (that maybe not support in the next major release), but after a major shift in the database engine happened, the library should follow with a major shift v2.* as well if changes needed, which may be AutoMigrate is tested and no longer supported because of many considerations, one of them could be the mass of work.

Later, another community participation takes place, and someone did the AutoMigration for v2.*, and so on...

from surrealdb.go.

I fully agree that migration capabilities are necessary. And we will be providing them through various different avenues (CLI tools, database functions, docker images are just some of the ideas for example). We need to keep in mind that this project, the golang drivers, are to provide a low-overhead, fully capable access to the database in such a way that doesn't interfere with people's application designs.

Regarding the versioning approach: that is a difficult one to respond to because you are right, we could do it that way. But at the same time, that is a lot of operational overhead. We need to track bugs for at least two live versions of the project. We will have people wanting different cardinality and justifying it by saying that we already do versioning this way. New users will be asking what is the correct version to use. Other language drivers will be asking when their 1.0-alternative is coming with such features.

I am thinking that migration functionality is scope creep for this particular project. It should be entirely possible to have this functionality in a separate project though, which could then be included in projects that require it.

from surrealdb.go.

Closing as there is already ongoing work to support migrations outside of drivers.
https://github.com/Odonno/surrealdb-migrations
We think this functionality may be out of scope for the drivers themselves. We would like to keep them lightweight and practical for all projects.

from surrealdb.go.