Am Freitag 12 Februar 2010 12:14:38 schrieb Kern Sibbald: > On Friday 12 February 2010 11:41:16 Philipp Storz wrote: > > Am Freitag 12 Februar 2010 11:21:55 schrieben Sie: > > > Le Vendredi 12 Février 2010 11:01:52, Philipp Storz a écrit : > > > > Am Freitag 12 Februar 2010 09:50:53 schrieben Sie: > > > > > Hello, > > > > > > > > > > Le Vendredi 12 Février 2010 09:41:51, Philipp Storz a écrit : > > > > > > > > - copy the examples/sample-query.sql to query.sql, as before, > > > > > > > > the "query" > > > > > > > > > > > > > > > > command had no queries. > > > > > > > > > > > > > > I don't know what this refers to. > > > > > > > > > > > > This refers to > > > > > > http://www.bacula.org/5.0.x-manuals/en/main/main/New_Features_in_ > > > > > >5_ 0_ 0. ht > > > > > > > > > > > >ml > > > > > > > > > > > > : --------------------------- > > > > > > > > > > > > Custom Catalog queries > > > > > > If you wish to add specialized commands that list the contents of > > > > > > the catalog, you can do so by adding them to the query.sql file. > > > > > > This query.sql file is now empty by default. The file > > > > > > examples/sample-query.sql has an a number of sample commands you > > > > > > might find useful. > > > > > > --------------------------- > > > > > > I think that a rpm package should directly use the > > > > > > sample-query.sql file installed as the query.sql file, as > > > > > > otherwise the query command would have no single entry. > > > > > > > > > > We now use an empty query.sql file because we don't want to support > > > > > custom queries across all database engines and all database > > > > > versions. > > > > > > > > > > If you still use the sample query file, support requests will > > > > > continue to come... > > > > > > > > > > In the 5.0.1 release, the first line of the query file explains > > > > > where the > > > > > > > > > > user can find samples. I think that you should do the same. (with > > > > > the appropriate RPM path) > > > > > > > > > > Bye > > > > > > > > Hello Eric, > > > > > > > > I understand what you are thinking about, but I think that having > > > > such a really useful command like "query" without any use in the > > > > default configuration is not the right way to do it. > > > > > > > > Maybe it would be possible to have at least one single command (like > > > > jobs are saved on a certain medium, or something even simpler) should > > > > be supported, so that a potential user has something to play with. > > > > > > Yes, this is possible, but it requires lots of work, if someone is > > > ready to write them and test them on a dozen of different databases, > > > why not. (it can be done step by step) > > > > Well, i think that this sounds exactly like something that could be > > tested automatically by an regression test. > > > > > (For example, SQLite3 versions between 3.50 and 3.60 have problems with > > > JOIN Table USING ()...) > > > > Do you have more information about problems regarding the query commands? > > Which one does not work etc. > > > > > An other solution can be to test them and have a sample-mysql.sql, > > > sample-postgresql.sql, etc... Your package will be able to choose the > > > right one. > > > > > > I personally don't have time to do it, so if any volunteers want to do > > > that, it's time to speak up... > > > > I would try to build first an regression test, in order to test if the > > queries work. What do you think about that? > > Philipp, > > The problem with regression testing at the moment, is that it is only done > on one SQL engine at a time. It requires a rebuilt from source to switch. > In the next major version after 5.0, we will probably be able to switch > databases dynamically, and possibly run multiple databases at the same > time. Of course, it would be much nicer if we could test more than one SQL query at one time, but as you know we run all three sql engines here at dassIT during the regression tests, so that we should find most of the problems with the different SQL engines.
> However, devising some regression tests is a good idea, and I am convinced > that there are SQL queries that can be implemented that work on all > backends. However, it requires someone like you to test them and ensure > they work. > > What I want to avoid is that users submit rather complex queries, then a > month or two later, we get a bug report on it and have to spend 3 hours > trying to find out what the query does (some SQL is not simple) and > discover that the syntax is incompatible with all but one SQL engine. I think that we could solve this problem by having a set of supported sql queries, and a set of unsupported/user proivded queries, which then can be provided in a different file like we have it now in the query-examples file. > The full solution to the problem not only requires the work Marco is doing > on the SQL engines, but also to add some new features to the query command > that will permit user defined queries and Bacula project defined queries > and to be able to define queries that are SQL specific. That is another > programming project that is not currently very high in our priorities. These changes of course would be nice, but in my opinion the queries that are already there now are already very useful. best regards, Philipp ------------------------------------------------------------------------------ SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev _______________________________________________ Bacula-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/bacula-devel
