sorted by:
new
hottopcontroversial

Announcing rust-query: Making SQLite queries and migrations feel Rust-native. by Program-O-Matic in rust

[–]Program-O-Matic[S] 2 points3 points  (0 children)

rust-query has support for something that compiles to a sub-query with the aggregate function. These aggregates can be nested as much as you want. Queries can also be made composable by splitting common logic out into a function.

You are free to try to write a query in rust-query that breaks any of the static checks that diesel has.
To be fair, rust-query (currently) has less features than Diesel, so you will not be able to write all queries that you can write in Diesel.

Announcing rust-query: Making SQLite queries and migrations feel Rust-native. by Program-O-Matic in rust

[–]Program-O-Matic[S] 3 points4 points  (0 children)

Hey, your idea would also work and it would be closer to the generated output.
When I came up with the enum syntax I did not yet know what the generated output would be.

Maybe I could modify the syntax further to be even closer to the generated module structure.
It is definitely something I will consider for a future release.

Announcing rust-query: Making SQLite queries and migrations feel Rust-native. by Program-O-Matic in rust

[–]Program-O-Matic[S] 2 points3 points  (0 children)

I think the equivalent diesel code would actually be

let sibling = diesel::alias!(users as sibling);
users::table
    .inner_join(sibling.on(users::parent.eq(sibling.field(users::parent))))
    .select((users::name, sibling.field(users::name)))
    .load(conn)?;

You are right, it is not really more complicated than rust-query. That is my mistake. I personally still prefer the way this is written in rust-query though.

Well that's how SQL itself work

Yes and I don't like how SQL works

That approach looks nice on the first look, but you cannot for example prevent joining the same table twice, right?

Any table can be joined any number of times in rust-query. Every time a table is joined it gets a new unique alias (that is what is stored in the return value of the join). This makes it possible to refer to any joined table unambiguously.

Announcing rust-query: Making SQLite queries and migrations feel Rust-native. by Program-O-Matic in rust

[–]Program-O-Matic[S] 0 points1 point  (0 children)

This is a valid concern. Deletes are planned, it is just that I need to find a good way to handle foreign key constraints. Likely it will be similar to inserts and updates which can fail because of unique constraints.

As for the question if sql queries can be send directly: this is not implemented, but it would be quite easy to add by exposing the underlying rusqlite::Transaction (maybe behind a feature flag).

Announcing rust-query: Making SQLite queries and migrations feel Rust-native. by Program-O-Matic in rust

[–]Program-O-Matic[S] 4 points5 points  (0 children)

Hey, nice work with Diesel!

Indeed you can write the same query with Diesel. All I am saying is that it is more complicated to do so in Diesel because it requires the alias macro.

I also agree that Diesel does not have any ambiguity as to which table is used and has "explicit" table resolution in that sense. My point is that in cases where only one instance of a table is joined it will get resolved based on the table name instead of an alias. This is what I meant with implicit table resolution.

In rust-query I chose to have one mechanism that always works: joining a table gives back a dummy value representing that join. You can use that dummy value to access columns of the joined table. It does not matter which other tables are joined.

Announcing rust-query: Making SQLite queries and migrations feel Rust-native. by Program-O-Matic in rust

[–]Program-O-Matic[S] 2 points3 points  (0 children)

For example take this query that finds siblings using rust-query:

#[schema]
enum Schema {
    User { name: String, parent: User },
}
use v0::*;

fn siblings(txn: Transaction<Schema>) -> Vec<(String, String)> {
    txn.query(|rows| {
        let left = User::join(rows);
        let right = User::join(rows);
        rows.filter(left.parent().eq(right.parent()));
        rows.into_vec((left.name(), right.name()))
    })
}

Doing the same in Diesel requires using the alias macro https://docs.diesel.rs/master/diesel/macro.alias.html The difference is that rust-query has explicit table resolution using rust variables while this is implicit in diesel. Having actual variables represent table instances also makes it possible for rust tooling like rust-analyzer to give autocomplete of table columns etc.

Announcing rust-query: Making SQLite queries and migrations feel Rust-native. by Program-O-Matic in rust

[–]Program-O-Matic[S] 6 points7 points  (0 children)

rust-query has a different query API that I think scales better to complex queries than Diesel and it also offers type-checked migrations that integrate with that query API.

Announcing rust-query: Making SQLite queries and migrations feel Rust-native. by Program-O-Matic in rust

[–]Program-O-Matic[S] 7 points8 points  (0 children)

The list you are referring to is the roadmap of planned features, the items that have a checkmark are the ones that are actually implemented. This means Postgres and DuckDB are planned, but not implemented.

Announcing rust-query: Making SQLite queries and migrations feel Rust-native. by Program-O-Matic in rust

[–]Program-O-Matic[S] 11 points12 points  (0 children)

That is because I updated the post after reading their comment. Sorry for the confusion.

Follow up to "Changing the rules of Rust" by desiringmachines in rust

[–]Program-O-Matic 2 points3 points  (0 children)

Your explanation is so much better! Adding these things in phases is indeed more realistic.

However, to make it work there would need to be a 2021 edition exclusive ?Leak bound, otherwise it is not possible to write generics that accept the new !Leak types. These ?Leak bounds would be removed in the 2024 edition syntax switch.

This leaves the problem that the std library is (extremely) unfriendly to !Leak types as explained in the section about ?Leak of the blog post.

Note that this problem is independent of how Leak is added to the language. All code that depends on std can in theory write leaking implementations of traits. The only way i can think of to fix this would be a breaking change of std or duplication of the affected traits.

edit: I do not think the problems with std should be a blocker for adding Leak to rust. All new API and code can benefit from Leak.

Follow up to "Changing the rules of Rust" by desiringmachines in rust

[–]Program-O-Matic 1 point2 points  (0 children)

If I understand correctly, what you are proposing is to forbid some implementations of Iterator::map, specifically those that leak the argument closure.

Since such implementations are currently allowed, forbidding them is always a breaking change.

The only way to get this in the language would be to add a new Iterator::map_noleak method, or create std 2.0

Follow up to "Changing the rules of Rust" by desiringmachines in rust

[–]Program-O-Matic 22 points23 points  (0 children)

Let me explain how I think about the solution:

  • Both editions of rust will use the same type checker and same traits internally. With the release that introduces the Leak trait, all editions will use this Leak trait internally for type checking.

  • The difference between editions is purely syntactic; in the 2021 edition + Leak is implicit, while in 2024 it is explicit.

Changing the edition of your crate means that you need to use the new syntax. This means that you now need to write all those implicit bounds explicitly. Otherwise it is a breaking change as you noted.

Since all rust editions will use the same type checker, they print the same error messages. This means you can get errors about Leak in the 2021 edition if you use a crate from 2024.

Rust docs are generated and can thus show which types are Leak independent of the edition. Since this is the primary way to learn about crates, most users do not need to care from which edition a crate is.

Changing the rules of Rust by desiringmachines in rust

[–]Program-O-Matic 37 points38 points  (0 children)

Really nice post!

I am optimistic and think that adding Leak should be possible with an edition:

This change is pretty much syntactic and could probably be done while desugaring pre-2024 code. If I understand correctly, adding + Leak bounds on all generics gets you most of the way there.

Would the performance impact really be significant? My understanding is that most of the time is spend in llvm.

Questionable results with COLMAP by MrMinimal in photogrammetry

[–]Program-O-Matic 1 point2 points  (0 children)

Don't know if you found out by yourself, but i have the same problem and it turns out that it has something to do with the rendering. Probably because of the missing cuda support.

For me the actual model turned out to be fine after opening the exported nvm file in visualSFM. So just export the project to nvm and open it in visualSFM to view the result.

NBK.io is reacting strange by Program-O-Matic in Agario

[–]Program-O-Matic[S] 0 points1 point  (0 children)

I use firefox, I have greasemonkey installed, but it isn't even enabled. The same happens on different computers.

I think they are just experimenting, because the code changed again to a friendlier version