[...]
I guess for my vision of this sort of database development UI tool I am channelling my secret shameful past use of Microsoft Access, whilst lots of it was bad, some of its interactive stuff was kind of useful :)
IMO it would be better if the query was copied to an editable (pane/entry) since whenever I have sql in code it usually has part of the query generated by code and this would need interpolating for the query to make sense at edit time.
Well... in my mind I had also something more, Steven suggested. Mark a query and execute it. The reason why I want such a support is, that I don't want to copy queries e.g. to pgadmin
Suggestion was *in addition* to just executing marked queries. Sure if the whole query exists in the source in executable form, just highlight it and execute. But as soon as something is being interpolated into it, (the "interesting" queries that I would want to try out) then it can't be executed at edit time unless the user can do that interpolation.
Display the results in a scrollable gtk table in the bottom pane. This was especially beneficial as the ASCII presentation from the command line is hard to see when it starts wrapping.
Or a separate editor buffer??
Well... also possible. Do you need some editor features on that buffer?
See below :)
Also you can cut and paste out of an edit buffer, but you can't from trees.
That would be a reasonable minimum. We could extend it from there to:
Show tables in the current database on the side panel, expandable to show the columns
Editable if supported by the underlying database, what about creating tables as well?
CREATE TABLE "foo"; should be not too complicated for everyone in first step IMHO.
Ummm, I was thinking of defining the columns too :) and for use during development it would be nice if it did the drop and re-create if the table already existed, or modified the columns if supported by the particular database. And maybe transferred the existing contents too :)
Allow editing of the cells in the table output
Which is where outputting to the edit buffer helps, save means commit changes?
Well... This is something, I was thinking of not having -- at least on versions. I just don't think it's needed to often by a developer. And everyone else could use pgadmin/phpmyadmin/*
Well, you did ask for suggestions :)
Anyway XXXadmin are specific tools, following on from Stevens comment, the Geany tools should be database independent. And editing data to correct the update you just tried would be useful.
Some further thoughts:
I used SQLAlchemy for my gedit plugin (it was in python) because it allowed connecting to various SQL databases such as MySQL, PostgreSQL, etc If there is a way to make the output in a table on a separate thread to not lock the UI, that would be good for larger result sets. We could at least create some optional built in limit of how many results. A way to kill the query in progress would be good
In current Geany thats best handled as a subprocess, which is also a good way of handling multi-database configurability, just run the command for the particular database.
I second that there should be a blocking UI when running a query -- by using the geany api it should be not often the issue anymore.
Well, good luck Frank, IIUC we can't even make modal dialogs block (at least on Unity and KDE :)
Cheers Lex
PS what about no-SQL databases, yeah I want everything ;-)
Cheers, Frank
Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel