This code (okay I made the use line up because it's not on the website and I'm lazy, you do need one though):
use some::stuff::for::the::dsl;
let versions = Version::belonging_to(krate)
.select(id)
.order(num.desc())
.limit(5);
let downloads = version_downloads
.filter(date.gt(now - 90.days()))
.filter(version_id.eq(any(versions)))
.order(date)
.load::<Download>(&conn)?;
Thanks to generics, all of this checking is computed at compile time. The end resulting code is the equivalent of
let results = handle.query("SELECT version_downloads.*
WHERE date > (NOW() - '90 days')
AND version_id = ANY(
SELECT id FROM versions
WHERE crate_id = 1
ORDER BY num DESC
LIMIT 5
)
ORDER BY date");
You can absolutely create an ORM _without_ generics, but it cannot give you the same level of guarantees at compile time, with no overhead.
It also heavily relies on generic types to ensure that everything is well-formed, and to provide zero overhead.
There's two variants on a single way: basically, a "schema.rs" file contains your schema. You can write it out, and (with the help of migrations) it will update it when you create a new migration, or, you can have it literally connect to the DB at compile time and introspect the schema.
> Also, type checking is negligible from a performance perspective, so I the "zero overhead" is of minimal interest.
Ah, but it's not "the type checking is fast", it's the "diesel can generate hyper-optimized outputs that don't do runtime checks". Like, as an interesting example, Diesel can (well, will be, this has been designed but not implemented yet) actually be _faster_ than a literal SQL statement. Why? The SQL literal is in a string. That means, at runtime, your DB library has to parse the string, check that it's correct, convert it to the databases' wire format, and then ship it off. Thanks to strong generics, since the statements are checked at compile time, none of those steps need to be done at runtime; the compiler can pre-compile that DSL into postgres' wire format directly.
The reason this hasn't actually been implemented yet is that it's admittedly a tiny part of the overall time, and the Diesel maintainers have more pressing work to do. I use it as an example because it's an easier one to understand than some of the other shenanigans that Diesel does internally. It couldn't remove this kind of run-time overhead without generics.
Few typesystems come close to that (Coq is one of the few languages where the system might be advanced enough), but generally you want to completely remove entire classes of errors.
How (well) does diesel deal with migrations? I've seen other ORMs fall down the stairs trying to deal with schema modification over time.
How (well) does diesel deal with migrations? I've seen other ORMs fall down the stairs trying to deal with schema modification over time.
"diesel migraiton run" will run all pending migrations, there's revert/redo as well. "diesel migration generate" can generate these files and directories for you; it doesn't yet (that I know of) have helpers to write the SQL though (like Rails does for its migrations).
On deploy, it runs the migrations first https://github.com/rust-lang-nursery/thanks/blob/master/buil...
I believe there are some interesting improvements coming down the line in the future, but for now, it works pretty well.
I would need one for each and every struct(table).
These days there is a tool that can generate all those struct methods: https://github.com/vattle/sqlboiler
So from the ORM perspective we (as the community) have worked around it.
Now Repository<T> and for us around 200,000 lines of code are gone and only one narrow set of tests to execute.
class Collection<T implements Entity> {
void insert(T entity) {
String vals = entity.props.map(escapeSql).join(",");
String qs = entity.props.map(x => "?").join(",");
PreparedStatement p = db.prepare("insert into %s (%s) values (%s);", this.tableName, qs, vals);
db.submit(p);
}
}
My specific problem when i realized it was an actual problem was when i tried to connect to a sql databse and working with a proper ORM.