phpgroupware-developers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Phpgroupware-developers] db abstraction for updates?


From: Alex Borges
Subject: Re: [Phpgroupware-developers] db abstraction for updates?
Date: Tue, 02 Dec 2003 12:53:09 -0600

For straight tables (one table apps or scarcely related table apps) you
can make a child of the entity class (in 16), and use the oo api it
provides to build db independent queries. You can then pass those to
your db calls. Some discussion on this is available in the wiki under
sql builder, and the documentation is also available online and pointed
to by the same wiki comments.

For multiple, intricated and related table apps, you can use the
sql_builder interface which groups entities and resolves joins. It is
not a simple interface and you should really check if you need such a
beast for a simple thing.

The sql builder framework is designed to be an interface that generates
complex sql statements based on a relational model expresed in
sql_entity class declarations. It looks like most object-to-relational
mappers in java and that kind of thing.

Beware, it is NOT a RecordSet access object, or any kind of iterator
interface, its a query resolver to which you pass criteria and it
returns to you plain sql (or executes it for you if thats what you
want). 




On Tue, 2003-12-02 at 10:57, Chris Weiss wrote:
> the everything a string style is poor programming.  MySql allows it, but it's
> still wrong to code like that.  I ersonally would like to see SQL objectized,
> but it's a very complex thing and certainly would add a whole lot of overhead.
>  In smaller scripts you probably wouldn't notice the difference, but in phpgw
> using it for every SQL call would be devistating to performance.
> 
> 
> Brad Bulger (address@hidden) wrote:
> >
> >
> > yeap.. when i found myself fixing the same insert command
> > in multiple places (because the 'everything is a string' mysql
> > style doesn't mix with postgres 7.3), though, i wondered if there'd
> > be some value in concentrating the update code a bit... like an
> > object that knew how to update a particular table, gen'd from
> > the table schema. or is that too much overhead?
> >
> > or maybe just a matter of style/taste. i'm coming from working with
> > the PEAR DB code, so i got used to a parameter-based style.
> >
> > thanks
> >
> > On Tue, 2 Dec 2003, Chris Weiss wrote:
> >
> > > just issue INSERT or UPDATE sql commands
> > >
> > > Brad Bulger (address@hidden) wrote:
> > > >
> > > > are there plans to add routines to handle inserts and updates to
> > > > tables via some kind of abstract layer, like the GetUpdateSQL()
> > > > and GetInsertSQL() functions in adodb 1.31? or do they exist, and it's
> > > > just a process of applying them in the various components? what
> > > > i can see - in the 0.9.16 branch code - seems to be mostly
> > > > read-oriented, but i thought i might just be missing something.
> > > >
> > > >
> > > > _______________________________________________
> > > > Phpgroupware-developers mailing list
> > > > address@hidden
> > > > http://mail.gnu.org/mailman/listinfo/phpgroupware-developers
> > > >
> > >
> > >
> > >
> > > _______________________________________________
> > > Phpgroupware-developers mailing list
> > > address@hidden
> > > http://mail.gnu.org/mailman/listinfo/phpgroupware-developers
> > >
> >
> >
> > _______________________________________________
> > Phpgroupware-developers mailing list
> > address@hidden
> > http://mail.gnu.org/mailman/listinfo/phpgroupware-developers
> >
> 
> 
> 
> _______________________________________________
> Phpgroupware-developers mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/phpgroupware-developers





reply via email to

[Prev in Thread] Current Thread [Next in Thread]