On 19 Jun 2005 at 18:40, Kern Sibbald wrote:
> 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.
Generally, you would define each class in a different file, and then
include whichever class you need.
>
> 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.
I have only looked at bacula-web from cvs just after you announced
the gui project. I havne't refereshed yet.
> 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 far, the main issue is how to manipulate dates and intervals. We
could do that all in PHP. There is no native function for adding a
period to a date. Libraries probably exist for that. In which case,
we could reduce bacula-web to simple SQL. I think. More
investigation is required.
--
Dan Langille : http://www.langille.org/
BSDCan - The Technical BSD Conference - http://www.bsdcan.org/
-------------------------------------------------------
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
