I‘m happy that my employer is supporting my work on Diesel. They are sponsoring my trip to RustWeek this year.
This gives you all the possibility to learn more about using Diesel, by attending the workshop there.
Remote
Georg Semmler
@weiznich@social.weiznich.de
0 Followers
0 Following
17 Posts
Joined February 09, 2024
BLOG:
GITHUB:
It's Friday again and therefore time for another update on Diesel, a Rust ORM and query-builder.
This was again a quite week, we got one new issue and one new PR. I nevertheless still struggle to go through all the PR's and suggestions from February.
I still came around to publish diesel-async 0.8.0, although there is no big announcement blog post this time. The release mostly contains smaller fixes and quality of life improvements. See the GitHub release for more details.
Another week ends, so it's time for another update on Diesel, a Rust ORM and Query Builder.
This week we got 2 PR's and 1 new bug report.
Otherwise I decided that it is finally time to move diesel-async to the Diesel organization, to make it clearer that it is maintained by the same person than the rest of Diesel.
There are still a lot of open PR's that I need to come back, but still lack the time to do that.
Tomorrow are holidays here, so this weeks update on Diesel is a bit earlier than usual.
This week we discovered one new issue and received 3 PR's
Time for another update on the ongoing work on Diesel, a ORM and Querybuilder for Rust.
This week I released Diesel 2.3.6 addressing a minor regression and enabling support for mysqlclient-sys 0.5. See the release announcements for details: https://github.com/diesel-rs/diesel/releases/tag/v2.3.6
We received 1 new bug report and 2 PR's this week.
It's Friday again, so it's time for another update on Diesel, a ORM and query builder for Rust.
I released Diesel 2.3.7 today, which fixes a potential memory leak in the SQLite backend.
See the full release notes for more details: https://github.com/diesel-rs/diesel/releases/tag/v2.3.7
Otherwise this was a really quite week, we only got one new PR.
@pointlessone@status.pointless.one @michalfita@mastodon.social @rayk@techhub.social @tomekw@functional.cafe I think I can at least give you all a clue on why such thing does not exist (yet?). From my perspective as someone in a position to potentially write such a thing the main thing missing is funding and potentially capacity to work on such large expansions. For context: I have some prototype stuff laying around that would make writing that crud stuff much easier for years now, I just do neither have the funding, the capacity nor the manpower to got it into an state to make it public in any reasonable way. If you know how to fix that I‘m happy to hear your suggestions
It's Friday again, so it's time for another update on Diesel, a Rust ORM and Query Builder.
This week we received 2 new bug reports and 3 new PR's. That hopefully gives me the chance to catch up at least on the PR's in the next weeks.
Come and see me at the @PrototypeFund@mastodon.social Demoday. I will be there presenting my work on adding support for Views to Diesel. You can attend the event for free by registering via the link below
From: @PrototypeFund@mastodon.social
@PrototypeFund@mastodon.social
@woshilapin@mamot.fr I had the time to cut a release today:
Replying to
@kornel @pid_eins I wonder whether it's still possible to fix that in rust's standard library. One quick and likely silly idea is to change std::path::Path and std::path::PathBuf to also optionally include a file descriptor and prepopulate that one on the first file system related sys-call. That might resolve most of those TOCTOU issues. It likely will break other stuff horribly, so for now that's just an silly idea without much research behind it.
Replying to
@kornel I think there are plans to change the various Range types in an also incompatible way with the next edition. It might be possible to do something similar here as well, at least that would give "us" the ability to change the internal layout in an incompatible way. Yes this would cause a lot of churn as old migrated code would then use something like std::edition_2024::path::Path instead of std::path::Path and likely get a deprecation warning for the old items at some point, but it doesn't seem to be impossible to change it. Especially given that the various std::fs functions all take generic arguments that require AsRef (not sure if we would get away with using the new path there, although I expect it should be fine as long as all currently existing variants are accepted there.).
That are obviously all unfinished quick ideas what could be tried. Any of that would need a bunch of research first if it is wanted and then what exactly is feasible and what not.
It's Friday again, so it's time for another update on Diesel, a ORM and QueryBuilder for Rust.
The news of the week is the release of Diesel 2.3.11, which contains fixes for potential panics while deserializing PostgreSQL server response, fixing batch inserts with returning clauses on SQLite and hardening some usage of SqliteConnection::deserialize_read_only_database(). Checkout the complete changelog for details:
https://github.com/diesel-rs/diesel/releases/tag/v2.3.11
This week we got 2 issue and 5 new PR's.
#rust #rustlang
It's Friday again, so it's time for another update on the work on Diesel, a ORM and query builder for Rust.
I published Diesel 2.3.12 today, which bumps the maximal supported libsqlite3-sys version to 0.38 and fixes an precision issue with Mysql's TIME types. See the release announcements for more details: https://github.com/diesel-rs/diesel/releases/tag/v2.3.12
We received no new bug report, but 10 new PR's this week. Several of the new PR's seek to add large new features so this required quite a bit of review time. Any help with reviewing changes to Diesel is welcome.
#rust #rustlang
Replying to
@ekuber@hachyderm.io I have opinions about this…
I agree with you that using the system version of a C library is usually the better solution, but implementing this is currently rather painful in rust.
Specifically this part:
Instead they should attempt to use the system one and bail if that fails, with an error asking people to enable a feature flag to use the vendored dependency.
is really hard to do correctly in a platform independent way.
*-sys crates currently can use various strategies to find system dependencies:
Asking the user to set an environment variable pointing to the correct library, which is painful to manage for the user as they need to set this for each *-sys crateUsing something like pkg-config to query the system about details of the library. This works reasonably well on standard linux/macos systems, but doesn't work anywhere else. (Especially not on windows…)Just set linker flags and pray that it will somehow work, which often works for reasonably configured system, but fails on systems where users set up stuff for developing the first time. (So it doesn't really work for new users unused to this kind of configuration, which is bad for obvious reasons).
Most *-sys crates I'm aware of use all three strategies in combination, with one overwriting the other. The bad thing about that is that the failure mode isn't: We did not find that library, but it's The linker emits a wall of text about undefined symbols. That's again really bad for new users. On the other hand that's likely something that the rust compiler itself could improve, e.g. by post-processing the linker output. I remember Pietro showed something along that line last year in Utrecht.
In addition to anything mentioned above there are other problems with system libraries. E.g. they might have different versions with different feature sets that need to be taken care of. That also might require different bindings for different versions. Or even such drastic things like a linux distribution "suddenly" starts shipping libxyz instead of libabc and just declares them compatible, although they are different. That happened with libmysqlclient vs libmariadb, which have mostly the same API and implement the same functionality but have different names and different behaviour and minor API differences in detail.
Overall I think there are certain points that could be improved in the ecosystem like better linker error messages better version to generally query for system libraries as crate under the rust-project, but I don't think this ever will cover all edge cases. I would go even as far and state that I would be surprised if it can cover all use cases for the top 100 *-sys crates or so.
Replying to
@rain@hachyderm.io Great Work. That seems like a really nice crate for creating maps from database types. Given that you might consider adding a wild card impl for IdHashItem based on diesels Identifiable trait so that you get these impls for free for all database structs.
(Obviously that's something you want to put behind a feature flag)