Is this project active?

[ghost]

Hi.

I want to help, but I want to know if this project is active. Is this project active?

[sj14]

Thanks for reaching out. Well, at least I try to keep the project alive but I haven't added new features for a long time. However, I would definitely accept community contributions. For example, when you want to add a new database and can do it easily without much refactoring, it should be easy to merge. What are you trying to achieve?

[ghost]

Hi sj14, thank you for feedback.

Interesting idea. How do you imagine the combination of usql and dbbench? As usql seems to be a command line application and otherwise also makes use of the "normal" SQL drivers.

It is not necessary to add new databases with dbbench, as it would be up to usql to support or not support the database we are going to benchmark.

That said, here's the next reason: I believe we should only focus on databases supported by usql. This ensures more discipline, focus, productivity. Even because it would be less work - imagine having the work of testing or add support each database individually in dbench for benchmark? (Can't we simplify our life as a developer?)

Also, I'm too lazy to support multiple database types with dbench - and if there's a project that already does this very well, I don't see why not use usql in dbbench. Why can't we unite the useful with the pleasant - I mean, an open project that supports different databases and a project that compares different databases?

I think in a general way, imagining that dbench is a wrapper with usql. That is, it uses usql in the backend, but it has other options with cli. My general idea when using usql is to reduce the complexity of the dbench project in terms of issues, PR - so that we can only focus on what is most important - that is, "our job is to create reports and scripts to compare different databases for better decision-making in information technology businesses". "This goal would only be achieved with usql and dbench."

Ah, I see dburl which might be a good fit to reduce the flag boilerplate of dbbench.

Our job would be just to create command line scripts to test ideas, concepts and compare with the existing database with usql in backend. We wouldn't have to worry about supporting different databases or even internal or external database configurations - since that job would be done by usql and not dbench.

dburl is not like usql, it's a different project. dburl is just connection strings to different databases, usql has command line support for connection strings to different databases along with other features.

[sj14]

In general, I agree with most of what you said.

I think in a general way, imagining that dbench is a wrapper with usql. That is, it uses usql in the backend, but it has other options with cli.

Here, I'm not sure. Do you mean something like calling usql from within dbbench, e.g. with os.Exec()? I would rather prefer implementing the necessary features from packages.

dburl is not like usql, it's a different project. dburl is just connection strings to different databases, usql has command line support for connection strings to different databases along with other features.

Sure, it's a different project, but also used inside usql which seems to ease the database connection handling.

I'm curious about more details how you would tackle it.

[ghost]

Hi sj14.

Here, I'm not sure.
Do you mean something like calling usql from within dbbench, e.g. with os.Exec()?

Yes, exactly.

I would rather prefer implementing the necessary features from packages.

But... why?(technical reason) API wrappers can simplify the process of interacting with APIs. An API wrapper provides a way to access an API through a particular programming language or interface, which can help streamline the process of making API calls.

But... why?(business reason) So... "Dbench" or "Dbench-Wrapper" provides a readable API that abstracts challenges of executing usql commands from within a go process for developers etc.

But... why?(personal reason) Well... argument in using wrapper... because my general idea is to have greater integration with usql in dbench. Also, you said yourself that you agree with most of the ideas. You said: "> In general, I agree with most of what you said."

But... why?(business and technical reason) In addition to these two arguments, we can separate the code into two layers: the database support layer and the database benchmarking layer. (This facilitates code management and also new features.) For example, in the benchmarking layer we can generate code on the command line for different databases - some users may need to have a place to save reports from different databases, we can support that (today things in the cloud are very common and we can make dbench a cloud service for different users, companies - For this to be possible, I'm thinking of using dbench as an api service for usql).

But... why?(personal reason) Another advantage is that because it is a command line for several databases, there is a customization option. It is possible to configure the same docker with 2 databases without having to do any special configuration since both are present as a driver in usql. Something that would previously be quite annoying to configure.

Sure, it's a different project, but also used inside usql which seems to ease the database connection handling.
I'm curious about more details how you would tackle it.

It's an interesting idea. Now thinking otherwise, it would be possible to do this with usql and dburl. You identify the url that will be for the database and direct it to the usql command line.

[sj14]

Do you mean something like calling usql from within dbbench, e.g. with os.Exec()?

Yes, exactly.

Unfortunately, I do not support this approach.

we can support that (today things in the cloud are very common and we can make dbench a cloud service for different users, companies - For this to be possible, I'm thinking of using dbench as an api service for usql).

You already seem to have an idea of which direction to go, so you can of course fork dbbench or start your own tool from scratch.

Sorry, that we don't agree on the technical approach but I wish you good luck and a lot of fun with your project ✌️💪

[ghost]

Hi sj14.

Unfortunately, I do not support this approach.
You already seem to have an idea of which direction to go, so you can of course fork dbbench or start your own tool from scratch.
Sorry, that we don't agree on the technical approach but I wish you good luck and a lot of fun with your project vmuscle

thank you for feedback.