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.

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.

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.

Best regards,

Kern

>
> 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



------------------------------------------------------------------------------
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

Reply via email to