On Sunday 19 June 2005 18:23, Dan Langille wrote:
> On 19 Jun 2005 at 18:19, Kern Sibbald wrote:
> > On Sunday 19 June 2005 15:23, Dan Langille wrote:
> > ...
> >
> > > I had some thoughts about how to handle different databases. I think
> > > we should have one file per database. For example:
> > >
> > > mysql.php
> > > postgresql.php
> > >
> > > Each of these files will contains functions that returns an SQL
> > > statement. That statement is then used by the main body of code.
> > >
> > > example:
> > >
> > > function sql_CalculateBytesPeriod($Server, $StartPeriod, $EndPeriod)
> > > {
> > > $sql = "
> > > SELECT sum(JobBytes) as jobbytes
> > > FROM job
> > > WHERE endtime < '$EndPeriod'
> > > AND endtime > '$StartDate'
> > > AND name='$server'";
> > >
> > > return $sql
> > > }
> >
> > I did something like this in Bacula by moving a lot but not all of the
> > SQL to a single file, dird/sql_cmds.c In the file, I use #ifdefs in the
> > few places where different SQL is required (when concatenating output of
> > two columns, and when creating temp tables).
> >
> > I regret doing this because it removes the SQL from the code, so each
> > time I want to understand or change the code I need to look at two files
> > this slows down programming and makes it more prone to errors (at least
> > for me).
> >
> > What you are suggesting would increase the programming time, because even
> > for SQL is identical: we would have to write it two times; we would also
> > have to modify it in two places; and as in what I did, the SQL would be
> > separate from the code that uses it.
>
> We could use classes.
>
> Define the basic SQL in one class. All other databases inherit
> from it and alter only the functions they need to alter.
Ah, now that sounds much more interesting especially if all the classes are
defined in a single file.
I don't have a problem with the above.
However, if we start from what we have now, I have the feeling that by a bit
of cleaver universal SQL, we could probably eliminate some of the tests with
two lines of different SQL that Juan Luis has implemented. In any case, what
he has done as it stands now doesn't bother me in the least so please don't
think I am complaning about it. If you haven't already looked at his code,
please do so. I suspect that you too will find it perfectly acceptable.
Of course, if we don't make an effort to write simple SQL standard code, it
all could get out of hand very fast the day that bacula-web needs to support
a few more databases.
So, for me, I don't have a problem with either your SQL class with redefined
functions that require different SQL or with the current implementation ...
--
Best regards,
Kern
(">
/\
V_V
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
