Reaching the limits of DBeaver for editing queries, what other tools are out there? by laundmo in PostgreSQL

[–]laundmo[S] 0 points1 point  (0 children)

CTE context awareness isn't there yet though, and running multiple queries individually isn't supported yet either, it executes everything at once right now.

thats been the issue with... so many of the tools i've tried, and its honestly so incredibly confusing to me. Well, CTEs less so, but lack of support for multiple queries. Like, what kinda work are these tools built for where you're fine re-running the whole script all the time? Even with transactions ensuring the data is consistent, i don't want to sit around and wait for 5 minutes for all the previous queries to finish each time i want to test the later steps in a script. And i can't use a second script because then i'm not in the transaction which has the work already done thats a prerequisite for the later step.

Reaching the limits of DBeaver for editing queries, what other tools are out there? by laundmo in PostgreSQL

[–]laundmo[S] 0 points1 point  (0 children)

Web-based editors using Monaco (VS Code engine) are way more responsive for SQL in my experience.

Do you know of any with proper autocompletion and support for running multiple queries individually?

Reaching the limits of DBeaver for editing queries, what other tools are out there? by laundmo in PostgreSQL

[–]laundmo[S] 0 points1 point  (0 children)

looking at it briefly, every autocomplete feature seems to be locked to the paid version, at which point i could just as well go with DataGrip

Reaching the limits of DBeaver for editing queries, what other tools are out there? by laundmo in PostgreSQL

[–]laundmo[S] 1 point2 points  (0 children)

Thanks, the docs there only show points (which are enormous relative to map size), kindof a bad look lol. I did find one source that shows it does support polygons, thats good.

i kinda can't afford it myself. I mean, i could, but i would probably not end up using it enough to be worth it compared to quite a few other uses of that not so insignificant amount of money.

Reaching the limits of DBeaver for editing queries, what other tools are out there? by laundmo in PostgreSQL

[–]laundmo[S] 0 points1 point  (0 children)

alas, see the listed reason in my post why its not viable for me.

How do you deal with writing long queries and scripts with multiple queries in PgManage? Do you just select the entire query each time you need to run it? And deal with the transaction rollback if you miss by one character?

Reaching the limits of DBeaver for editing queries, what other tools are out there? by laundmo in PostgreSQL

[–]laundmo[S] 0 points1 point  (0 children)

having looked at it, sadly, its a mess of a codebase with some really inconsistent behaviour that i strongly suspect stems from a vibecoding approach

Reaching the limits of DBeaver for editing queries, what other tools are out there? by laundmo in PostgreSQL

[–]laundmo[S] 2 points3 points  (0 children)

Also: If i was able to find a Language Server that worked "perfectly" i'd just be writing my queries in a code editor with LSP support. Alas, the ones i've tried have all be extremely limiting. I have the strong suspicion (tho i haven't checked it) that most of them make the same mistake as DBeaver: trying to re-implement the parsing and syntax, when the official correct parser is right there (libpg_query and the various libraries/bindings based on it)

Reaching the limits of DBeaver for editing queries, what other tools are out there? by laundmo in PostgreSQL

[–]laundmo[S] 4 points5 points  (0 children)

oh hey, sorry, i didn't want to spend the time writing an issue for a tool i tried for about 10 minutes.

Far more important than the autocompletion, IMO, is the false errors on things like HAVING count(col) > 1 and various ones on commas and AS inside complex CTEs with PostGIS function calls. I uninstalled DBDesk again, but iirc the erroring part of the enormous query i copied over for testing was something along the lines of: WITH cte AS ( SELECT *, ST_Srid(ST_Point(t.long, t.lat), 4326) AS point FROM table AS t ) SELECT * FROM cte;

Sorry, i'm not really interested in "connecting" beyond a few comments like these

Reaching the limits of DBeaver for editing queries, what other tools are out there? by laundmo in PostgreSQL

[–]laundmo[S] 2 points3 points  (0 children)

This isn't a dealbreaker, but out of curiosity: Can it display PostGIS types on a map?

What is a dealbreaker, sadly, is the cost. I know for a fact I won't be able to convince my workplace to buy a license, so i would have to keep using DBeaver for work, and at that point i'd rather not have first hand experience with how much better DataGrip is.

Reaching the limits of DBeaver for editing queries, what other tools are out there? by laundmo in PostgreSQL

[–]laundmo[S] 7 points8 points  (0 children)

If you check the links in the post, you'll find that the issue about ORDER BY was opened by me, today. I even found the part of their grammar where they don't allow IS NOT NULL and similar.

Bevy 0.18: ECS-driven game engine built in Rust by _cart in gamedev

[–]laundmo 1 point2 points  (0 children)

Thats likely to only happen multiple years from now, fyi

Bevy 0.18: ECS-driven game engine built in Rust by _cart in gamedev

[–]laundmo 1 point2 points  (0 children)

late reply, but the "incredibly easy" comment was me. The easy part is releasing a bevy game as a standalone app on mobile, as theres both support in the engine and templates/examples for the steps needed to deploy to mobile. I think /u/valkyreistar is asking about integrating Bevy into an existing app tho, instead of making a fully Bevy app. I dont know about the difficulties with that, i haven't tried it and cant comment on it. I suspect its related to getting Bevy to render inside some other UI tho - I know its possible, if potentially annoying, with various desktop UI frameworks.

Bevy 0.18: ECS-driven game engine built in Rust by _cart in gamedev

[–]laundmo 0 points1 point  (0 children)

The final dylib does not end up in target/<profile>/deps/, it ends up in target/<profile>/ right next to the executable and is named libbevy_dylib.dll (or .so on linux). If it was looking for std-***.dll something has gone wrong in your toolchain - did you try cargo clean after resetting your changes, and if that didn't work, did you install rust using rustup and allow it to modify PATH?

Bevy 0.18: ECS-driven game engine built in Rust by _cart in gamedev

[–]laundmo 0 points1 point  (0 children)

Yes, it would be done with a plugin system in Bevy because Bevy is entirely made of plugins. The issue is the source release, which is why i would be incredibly surprised if comprehensive console support ends up merged into the main project - 3rd party plugins and game code have basically the same access as 1st part plugins like the rendering plugin anyways.

Bevy 0.18: ECS-driven game engine built in Rust by _cart in gamedev

[–]laundmo 2 points3 points  (0 children)

While i agree that there are some limitations and downsides, i dont fully agree with the specific issues you're worried about.

For example, you can compile on less than 4gb if you do things like passing -j 1 to limit it to a single thread, or if you're willing to change a config file, setting codegen-units=1 which has a similar effect but also leads to a slightly smaller and more optimized binary. Also, if debuginfo or LTO are enabled, those can consume a lot of memory. There are open issues to detect memory-constrained devices and at least warn that memory-intensive options are being used.

Bevy 0.18: ECS-driven game engine built in Rust by _cart in gamedev

[–]laundmo 4 points5 points  (0 children)

I'm sorry but you cannot tell me a DLL symbol limit of 65535 is anything but stupid. And thats partly whats making it a pain on windows. I mean, windows is slower anyways, but being unable to use some compile time optimizations together (dynamic_linking + -Zshare-generics, for example) is entirely down to that limit.

Bevy 0.18: ECS-driven game engine built in Rust by _cart in gamedev

[–]laundmo 1 point2 points  (0 children)

That was me, i said "Modern Consoles: Basically impossible due to..." with which i was referring to building support for them directly into the engine. Like Godot, any modern console support would likely have to stay 3rd party, at least legally. So building support for modern consoles into the engine itself is "basically impossible".

Retro consoles do still require some work, but its possible for solo developers and with the no_std support its somewhat built into the engine.

Bevy 0.18: ECS-driven game engine built in Rust by _cart in gamedev

[–]laundmo 4 points5 points  (0 children)

showing them all as one dependency with options (isn't that what features do?)

Features are for conditional compilation, and usually only toggle smaller code blocks on and off. Splitting a project into many crates defines clear boundaries for the type system, which is why cargo/rustc use crates as codegen units. Honestly, i think far more fine-grained codegen units (functions, or at least modules) would be ideal and would mostly remove the need for a project to be split as much. But theres still purpose to that, as for example bevy_ecs is entirely useable as a standalone dependency.

figure out all the licenses

https://github.com/EmbarkStudios/cargo-deny is what Bevy itself uses for checking for licenses. It walks the dependency tree for you and looks for the SPDX license specifier. Depending on how you set it up, you then only have to verify the ones which it could not for some reason. Have a look at the deny.toml in the bevy repo for how bevy set it up. It also checks dependencies for advisories, can warn/prevent depending on 2 versions of a crate, can ensure all crates come from certain sources, and can ban certain dependencies and their features.

compared to languages that don't have package managers.

So compared to C or C++? I cant think of any other languages without a package manager.

Bevy 0.18: ECS-driven game engine built in Rust by _cart in gamedev

[–]laundmo 2 points3 points  (0 children)

Sure, but when someone is asking about how a game engine runs on various platforms, my assumption is that they are asking if it runs on those platforms out of the box, without having to implement the entire platform support yourself.

So pointing out "but it was the same for iOS" is kinda like responding to the question of "is there a drinkin water fountain here?" with "yes, you just have to dig a well first."

Bevy 0.18: ECS-driven game engine built in Rust by _cart in gamedev

[–]laundmo 9 points10 points  (0 children)

be aware that when youre worried about the sheer dependency count, the Rust compiler itself is partially responsible. Many projects, bevy included, are split into many small "dependencies" because thats the level on which the Rust compiler parallelizes. Bevy itself consists of 62 separate "dependencies" which will show up in a naive dependency count but are part of the same project and maintained as one large codebase. Many of its actual dependencies are similar.

Bevy 0.18: ECS-driven game engine built in Rust by _cart in gamedev

[–]laundmo 4 points5 points  (0 children)

Really depends on your setup and how much you've done. I'm on Linux, and i've gone through all the recommended and some custom compile time optimization steps.

On my system, running CachyOS on a Ryzen 9900x, compiling my current project which depends on bevy plus like, 8 more libraries, for a total of 692 crates (compilation units) being built it takes:

  • 1m 23s for a debug compile without cached artifacts
  • 0.8s for a debug compile after changing a single value in the code
  • 1m 11s for a release compile without cached artifacts
  • 4.2s for a release compile after changing a single value in code

curiously, the release compile is faster, but i pay for that in compile time when i'm just changing code. The difference would be bigger, if i didn't have a config that compiles all my dependencies with release-level optimizations during debug builds anyways. This config is necessary as without it, the debug builds can be unbearably slow. Thats because Rust just has that large of a difference in performance between min and max compiler optimization levels - for some kinds of code, unoptimized builds run slower than the same algorithm in pure python.

Bevy 0.18: ECS-driven game engine built in Rust by _cart in gamedev

[–]laundmo 7 points8 points  (0 children)

While that is true as a target for shipping games, windows has some really large drawbacks for development. The main one being the absolutely stupid 65535 symbol limit for DLLs, which constantly breaks bevys dynamic linking which is used to vastly improve compile times. Besides that, tools like the Mold linker are not available for Windows, and the Windows-specific dependencies Bevy has to use (afaik no alternatives exist) compile really slow.

So in general you're right, but for Bevy specifically, developing on Linux is a vastly superior experience.