10 ms·

The problem with this approach is that you are forced to work in a subset of SQL due to the type system mismatch of SQL and the host language. A "proper" solut

by u320 11y ago

The problem with this approach is that you are forced to work in a subset of SQL due to the type system mismatch of SQL and the host language. A "proper" solution to this problem requires language changes (as Microsoft did with C# 3.0).

rabidferret 11y ago
You should take a closer look at what Diesel is doing with it's query builder. We actually do attempt to support the full power of every supported backend (of course there's still holes which need to be filled), with proper type guarantees which map to the semantics of Postgres. The main difference being that Diesel can check your queries for correctness at compile time.
- u320 11y ago
  The problem is that joins and projections give rise to new record types. The only way to support this in a type safe and natural way is if you have anonymous records in the host language, which Rust doesn't. On top of this there is some other metaprogramming stuff that is necessary in order to facilitate the DSL embedding. Look at what Microsoft did with LINQ. You can't pull that off in Rust no matter how much you want to.
  - tatterdemalion 11y ago
    This can be accomplished with procedural macros.
    - rabidferret 11y ago
      This can be accomplished without procedural macros, too. ;)
  - andrewflnr 11y ago
    Nevertheless, the goal here is to build an ORM for Rust. Why waste time describing what you think it can't do?
lobster_johnson 11y ago
While it's true that solving this at the language level would be even better, it's not required. All you need is an extensible AST data model. For example, ActiveRecord doesn't have support for window functions, but its underlying AST (a library called ARel) allows you to extend it, which at one point I did, allowing me to write something like this: things = Arel::Table.new('things') things.project(Arel::Nodes::NamedFunction.new(:sum, [things.count]).over('my_window')). window('my_window'). order(things[:name]). range(Arel::Nodes::Preceding.new) which generates something like: select sum(count(*)) over my_window from things window my_window as (order by name rows unbounded preceding) (It's been a while since I looked at this particular code, which is no longer in production use, so it might not be correct.) In other words, I could continue to express whatever I wanted of SQL, at the language level — no type mismatches. The SQL builder code isn't pretty, to be sure, but it's something you typically encapsulate into a lower-level module rather than writing in application code. And as it's highly analogous to the SQL code it generates, it's not like it's that much more complicated. (ARel isn't a shining example of how to do it right, either. I expect Diesel implements the AST aspect more cleanly.) Edit: I see what you're saying about typed record types. I was thinking more about the grammar, not the shape of the data.
- u320 11y ago
  Yes I should have been more clear that I was talking about a static typing context. In a dynamic language the problem is much easier, as you are basically only limited by your languages metaprogramming facilities.
  - RussianCow 11y ago
    But isn't the same true for a statically typed language with sufficiently powerful macros? I don't know if Rust falls into that category, having never used it, but I don't think it makes a difference whether the metaprogramming happens during compile time or runtime.
    - ossreality 11y ago
      Yeah, if they're talking about what I think they're talking about, yes, something like LINQ could be implemented with macros (compiler plugin variant, I think) in Rust.
scardine 11y ago
SQLAlchemy is a Python ORM that matches SQL almost 1:1. The main reasons I like this approach are: * it makes way easier (and safer) to reuse query parts compared to string composition/interpolation * the ORM takes care of differences between the backends, so it is easier if I have to port the application to another RDBMS.

by u320 11y ago

rabidferret 11y ago

You should take a closer look at what Diesel is doing with it's query builder. We actually do attempt to support the full power of every supported backend (of course there's still holes which need to be filled), with proper type guarantees which map to the semantics of Postgres. The main difference being that Diesel can check your queries for correctness at compile time.

u320 11y ago
The problem is that joins and projections give rise to new record types. The only way to support this in a type safe and natural way is if you have anonymous records in the host language, which Rust doesn't. On top of this there is some other metaprogramming stuff that is necessary in order to facilitate the DSL embedding. Look at what Microsoft did with LINQ. You can't pull that off in Rust no matter how much you want to.
- tatterdemalion 11y ago
  This can be accomplished with procedural macros.
  - rabidferret 11y ago
    This can be accomplished without procedural macros, too. ;)
- andrewflnr 11y ago
  Nevertheless, the goal here is to build an ORM for Rust. Why waste time describing what you think it can't do?

lobster_johnson 11y ago

While it's true that solving this at the language level would be even better, it's not required. All you need is an extensible AST data model. For example, ActiveRecord doesn't have support for window functions, but its underlying AST (a library called ARel) allows you to extend it, which at one point I did, allowing me to write something like this: things = Arel::Table.new('things') things.project(Arel::Nodes::NamedFunction.new(:sum, [things.count]).over('my_window')). window('my_window'). order(things[:name]). range(Arel::Nodes::Preceding.new) which generates something like: select sum(count(*)) over my_window from things window my_window as (order by name rows unbounded preceding) (It's been a while since I looked at this particular code, which is no longer in production use, so it might not be correct.) In other words, I could continue to express whatever I wanted of SQL, at the language level — no type mismatches. The SQL builder code isn't pretty, to be sure, but it's something you typically encapsulate into a lower-level module rather than writing in application code. And as it's highly analogous to the SQL code it generates, it's not like it's that much more complicated. (ARel isn't a shining example of how to do it right, either. I expect Diesel implements the AST aspect more cleanly.) Edit: I see what you're saying about typed record types. I was thinking more about the grammar, not the shape of the data.

u320 11y ago
Yes I should have been more clear that I was talking about a static typing context. In a dynamic language the problem is much easier, as you are basically only limited by your languages metaprogramming facilities.
- RussianCow 11y ago
  But isn't the same true for a statically typed language with sufficiently powerful macros? I don't know if Rust falls into that category, having never used it, but I don't think it makes a difference whether the metaprogramming happens during compile time or runtime.
  - ossreality 11y ago
    Yeah, if they're talking about what I think they're talking about, yes, something like LINQ could be implemented with macros (compiler plugin variant, I think) in Rust.

scardine 11y ago

SQLAlchemy is a Python ORM that matches SQL almost 1:1. The main reasons I like this approach are: * it makes way easier (and safer) to reuse query parts compared to string composition/interpolation * the ORM takes care of differences between the backends, so it is easier if I have to port the application to another RDBMS.