Feature request: Table migration based on structs

[flip111]

I searched to see if this was requested before, it seems a bit similar to https://github.com/diesel-rs/diesel/issues/1086 but this issue is only about structural migration (DDL - data definitional language, subset of SQL).

Could diesel detect changes in Queryable and Insertable structs and write migration code to up.sql and down.sql?

This is very common in many orm's and frameworks. I personally know this functionality from Doctrine (PHP) and Django (Python) i suspect Rails (Ruby) has it too.

On a side note: this is kind of the reverse of https://github.com/diesel-rs/diesel/issues/1589

[sgrif]

https://github.com/diesel-rs/diesel/issues/1583#issuecomment-370186178

[flip111]

Hi, thanks for your response. With the discussion about down migrations and DSL's does your comment also apply to up migrations based on generating SQL from queryable/insertable structs? I might be missing some background information, i couldn't tell.

[sgrif]

Sorry, I left out some context from previous discussions about this.

I don't think there's enough value in a rust-based migration DSL to justify the cost of maintenance. The only argument I've heard in favor of them (other than "I just don't want to write SQL migrations", which I don't find compelling) is that you're able to get down for free. I don't think that use case is compelling enough for such a feature to live within Diesel itself. I'm happy to help others implement it as a third party plugin.

Systems like Django ORM in Python or Data Mapper in Ruby where the migrations are generated from a model don't make much sense for Diesel, since structs which implement Queryable are not assumed to be one-to-one with a database table.

[flip111]

What if you take the fields of all structs that related to a single table. Put them in a (single) unique list. Compare that with the database columns. When the database has an extra column or is missing a column write out the SQL migration for it?

Are the facilities there to inspect the mapping (structs - tables)? Or would one have to write their own macros for it?

[sgrif]

Diesel doesn't assume or enforce that your structs are in anyway tied to table schema. If you wanted to write a library built around that for use with Diesel, I'd be happy to help with implementation questions.

[flip111]

Diesel doesn't assume or enforce that your structs are in anyway tied to table schema.

As far as i know that is the definition of Object-Relational Mapping to do just that. Now i'm utterly confused.

[sgrif]

Queryable represents the result of a SQL query, which may or may not represent the entirety of a single database table. Often they represent only a few columns of a table, values from multiple tables, or values which aren't representative of a single database column at all

[sgrif]

Or to put it another way, table! declarations are what is one-to-one with your database schema in Diesel. We choose to generate those from your database schema, rather than generating your database schema from Rust declarations. You have to write one of those two, we chose the one which more precisely represents what you actually mean

[flip111]

I understood the Queryable/Insertable structs to be the value containing "objects" (the O in ORM). Can table! hold values? I mean the values that go into and come from the database.

In the docs i see #[table_name = "posts"] i think this annotation does tie the struct below it to the posts table. Or is nothing assumed/enforced here? No check with the schema (table!)? If not, what is the posts string used for?

I'm just trying to understand this by the background of another (non-rust) ORM i used to work with ...

[sgrif]

[table_name] is used by other traits, but not by Queryable

On Tue, Mar 6, 2018, 7:37 PM flip111 notifications@github.com wrote:

I understood the Queryable/Insertable structs to be the value containing "objects" (the O in ORM). Can table! hold values? I mean the values that go into and come from the database.

In the docs i see #[table_name = "posts"] i think this annotation does tie the struct below it to the posts table. Or is nothing assumed/enforced here? No check with the schema (table!)? If not, what is the posts string used for?

I'm just trying to understand this by the background of another (non-rust) ORM i used to work with ...

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/diesel-rs/diesel/issues/1590#issuecomment-371002552, or mute the thread https://github.com/notifications/unsubscribe-auth/ABdWK0NmaCIrNlnhswcFiKRnEnWopcbeks5tb0fvgaJpZM4SfGeV .

[flip111]

The library looks well made, thanks for writing it. However i must conclude this is not an ORM. As far as i understood the insertable are based on the names of fields and the queryable on the order of fields. This does not give the user the freedom to create a mapping.

For relations i read in https://docs.diesel.rs/diesel/associations/index.html

Associated data is typically loaded in multiple queries (one query per table). This is usually more efficient than using a join, especially if 3 or more tables are involved. For most datasets, using a join to load in a single query transmits so much duplicate data that it costs more time than the extra round trip would have.

I like to see some numbers with the claim of efficient. Traditional database wisdom says to use joins for maximum query performance and a single roundtrip. It is expensive to deduplicate the data for sure. But it also gives you the possibility to construct an object graph and manage relations.

From that point many ORM's introduce the concept of Unit of Work where changes are made to the objects and then once committed update the database in the least amount of changes. This isn't necessary though but it gives you the opportunity to decouple your data changes with your database inserts.

ORM's have their own problems though, so this query-first approach is excellent in many cases. Again diesel looks like a very good library ... i just went in with the wrong expectations i think after seeing "ORM".

[sgrif]

I'm not interested in debating the meaning of the term ORM. Thanks for bringing up your concerns. :)