FlameRobin

Hi all,

I'm thinking how to implement SQL command history with new config stuff. 
History should be stored per-database. I have few things I'm not clear 
about:

- do we store history together with other config stuff (in same file)?

If yes:

- how do we name the keys? (perhaps something like: DATABASE/HISTORYx, 
where x = 0,1,2,3,...  ?)

- does it support multiline text (i.e. with newlines inside) ?

If no:

- can we use existing things like wxFileConfig() to read/write these 
kind of things?

Perhaps we could convert tabs and newlines into escape sequences, a 
write that? If not, I'm willing to create our own per-database 
history_reader/writer.

-- 
Milan Babuskov
http://fbexport.sourceforge.net
http://www.flamerobin.org

Re: [Flamerobin-devel] SQL commands history and new .conf files From: Nando Dessena <nando@de...> - 2005-08-24 12:11 Milan, M> I'm thinking how to implement SQL command history with new config stuff. M> History should be stored per-database. I have few things I'm not clear M> about: M> - do we store history together with other config stuff (in same file)? I'm not sure about it. If it's not a huge amount of data, then we're probably ok. But should it really be per-database? Is there no advantage in having it cross database boundaries? Also, is there some value in identifying history entries (or groups of entries) in some way, or does the user just create a script if it needs to? How does the UI look like? I'd expect a list/grid with all the statements in the history, possibly a memo to show the currently selected history item in its entirety (it could be more than one statement, couldn't it?) and a way to copy one of them to the SQL editor buffer. Is this close to what you have in mind? If so, I'd appreciate a multi-select capability. M> - how do we name the keys? (perhaps something like: DATABASE/HISTORYx, M> where x = 0,1,2,3,... ?) Well the DATABASE part is a given if you just do: Database d = ... d.setConfigValue("history1", ...); M> - does it support multiline text (i.e. with newlines inside) ? Not sure about it. I have seen that wxFileConfig does escape some characters, though, so I'd suggest you ignore the issue and see what gets written to the config file. M> If no: M> - can we use existing things like wxFileConfig() to read/write these M> kind of things? In any case, yes. At worst, we'll have to do this: M> Perhaps we could convert tabs and newlines into escape sequences, a M> write that? in Config itself, as it would be of more general use than simply history. Ciao -- Nando Dessena http://www.flamerobin.org

Re: [Flamerobin-devel] SQL commands history and new .conf files From: Milan Babuskov <albis@EU...> - 2005-08-24 12:42 Nando Dessena wrote: > I'm not sure about it. If it's not a huge amount of data, then we're > probably ok. Define huge. :) > But should it really be per-database? Is there no > advantage in having it cross database boundaries? There is if you have databases with the same structure. But even then I find it more distrupting then helpful. > Also, is there some value in identifying history entries (or groups of > entries) in some way, or does the user just create a script if it > needs to? We provide logging for that. You have the log file, multiple log files, and logging to database so you can simply copy/paste or do a "select * from flamerobin_log". > How does the UI look like? Two buttons on SQL frame: Back and Forward. Nothing more. By clicking, the current buffer is replaced with buffers from history. > Well the DATABASE part is a given if you just do: > > Database d = ... > d.setConfigValue("history1", ...); Ok, fine. > Not sure about it. I have seen that wxFileConfig does escape some > characters, though, so I'd suggest you ignore the issue and see what > gets written to the config file. Ok, I'll try it out. > M> - can we use existing things like wxFileConfig() to read/write these > M> kind of things? > > In any case, yes. At worst, we'll have to do this: > > M> Perhaps we could convert tabs and newlines into escape sequences, a > M> write that? > > in Config itself, as it would be of more general use than simply > history. Ok. I guess I'll have to try it out, and see how it works. -- Milan Babuskov http://www.flamerobin.org

Re: [Flamerobin-devel] SQL commands history and new .conf files From: Nando Dessena <nando@de...> - 2005-08-24 19:01 Milan, >> I'm not sure about it. If it's not a huge amount of data, then we're >> probably ok. M> Define huge. :) in the thousands. >> But should it really be per-database? Is there no >> advantage in having it cross database boundaries? M> There is if you have databases with the same structure. But even then I M> find it more distrupting then helpful. Here's why I thought about that: in my current main job I use 90% of the time the same database structure. Dozens of databases, all with the same structure. The remaining 10% I use another database structure, with just two or three instances. Two database structures in total, and I'd find it a nice feature just to be able to share the history among databases. Perhaps you could just have a config option like "statementHistoryGranularity" which can be global, per-server, per-database... The code to handle it would be similar to that of the metadata item property frame, which is not much complex and doesn't add clutter. The option could default to per-database. How does it sound? BTW, you'll also need a "statementHistorySize" option. >> Also, is there some value in identifying history entries (or groups of >> entries) in some way, or does the user just create a script if it >> needs to? M> We provide logging for that. You have the log file, multiple log files, M> and logging to database so you can simply copy/paste or do a "select * M> from flamerobin_log". OK, I keep mixing the two. >> How does the UI look like? M> Two buttons on SQL frame: Back and Forward. Nothing more. Right. A bare-bones UI looks adequate for it. >> Well the DATABASE part is a given if you just do: >> >> Database d = ... >> d.setConfigValue("history1", ...); M> Ok, fine. You could encapsulate the circular buffer in a suitable class that handles the interaction with the config. Ciao -- Nando Dessena http://www.flamerobin.org

Re: [Flamerobin-devel] SQL commands history and new .conf files From: Milan Babuskov <milanb@km...> - 2005-08-24 21:02 Nando Dessena wrote: >>>I'm not sure about it. If it's not a huge amount of data, then we're >>>probably ok. > > M> Define huge. :) > > in the thousands. Ok, in that case, let start with config and see how it works. >>>But should it really be per-database? Is there no >>>advantage in having it cross database boundaries? > > M> There is if you have databases with the same structure. But even then I > M> find it more distrupting then helpful. > > Here's why I thought about that: in my current main job I use 90% of > the time the same database structure. Dozens of databases, all with > the same structure. The remaining 10% I use another database > structure, with just two or three instances. Two database structures > in total, and I'd find it a nice feature just to be able to share the > history among databases. Perhaps you could just have a config option > like "statementHistoryGranularity" which can be global, per-server, > per-database... per-credentials... ? > The code to handle it would be similar to that of the > metadata item property frame, which is not much complex and doesn't > add clutter. The option could default to per-database. How does it > sound? Ok. I'll add it to SQL editor options in Preferences: Share SQL statement history (o) between all databases ( ) between databases on same server ( ) between databases with same display name ( ) don't share (each database has its own) The last one would be default, although I think I'll be using the third one myself. I have some 7-8 servers registered, and similar databases exist on various servers. On one server, I rarely have the same databases. > BTW, you'll also need a "statementHistorySize" option. Yep, that too. > You could encapsulate the circular buffer in a suitable class that > handles the interaction with the config. Yep. I plan to call it History or StatementHistory. It would have methods like: next(), previous(), first(), last(), isAtEnd(), isAtStart(), etc. -- Milan Babuskov http://fbexport.sourceforge.net http://www.flamerobin.org

Re: [Flamerobin-devel] SQL commands history and new .conf files From: Milan Babuskov <milanb@km...> - 2005-08-27 14:55 Milan Babuskov wrote: >> You could encapsulate the circular buffer in a suitable class that >> handles the interaction with the config. > > Yep. I plan to call it History or StatementHistory. It would have > methods like: next(), previous(), first(), last(), isAtEnd(), > isAtStart(), etc. I implemented it, but there's an issue I'm not sure about: Since history can be stored in many ways: per-server, per-database, per-database_name, and globally, I made it format config keys differently for each variant. It does work, but I feel that we need to somehow enable the future storing-into-separate-files. -- Milan Babuskov http://fbexport.sourceforge.net http://www.flamerobin.org

Re: [Flamerobin-devel] SQL commands history and new .conf files From: Milan Babuskov <milanb@km...> - 2005-08-27 14:55 Nando Dessena wrote: > M> - does it support multiline text (i.e. with newlines inside) ? > > Not sure about it. I have seen that wxFileConfig does escape some > characters, though, so I'd suggest you ignore the issue and see what > gets written to the config file. It escapes newlines too, so it works. -- Milan Babuskov http://fbexport.sourceforge.net http://www.flamerobin.org

Re: [Flamerobin-devel] SQL commands history and new .conf files From: Nando Dessena <nando@de...> - 2005-08-29 06:49 Milan, M> Since history can be stored in many ways: per-server, per-database, M> per-database_name, and globally, I made it format config keys M> differently for each variant. It does work, but I feel that we need to M> somehow enable the future storing-into-separate-files. 1) as I have written elsewhere, I can't see the usefulness of storing per-server; also per-database_name seems less than intuitive. 2) I can't get the problem in your last sentence. What's the matter? Ciao -- Nando Dessena http://www.flamerobin.org

3 messages have been excluded from this view by a project administrator.