Re: [Phpgroupware-developers] XML & Schema Proc

[Ralf Becker]

Michael Dean wrote:
> On Fri, 2003-05-02 at 03:41, Ralf Becker wrote:
>
> > The alpha support for table-creation in ADOdb can also be seen as a 
> > change to influence their development, as I have to agree with Michael: 
> > our / his schema_proc classes are far ahead of every other project of 
> > this kind.
>
> Again, we already have good functionality that just needs enhancement.

I think the key point in that discussion is not "is ADOdb better/faster 
then our phplib db-layer", it is "do we have someone to maintain and 
expand (new db's or capabilities of existing ones) the class/framwork". 
I'm more than happy if your back to do so. If not, I would still 
consider to hook up with ADOdb and "sell" them our schema_proc 
framework, to maintain and further develop it.

> > I did most of the maintaining (bug-fixing) of the db-classes and 
> > schema_proc in the last year and I can only support knecke in this.
> >
> > The half a dozent postgres bugs I fixed in the last half year, shows / 
> > supports the benefits of bigger user-base in testing the schema_proc 
> > classe. Heres a short / not complete list:
> > - sequnces had not been droped, when a table got droped (you could not 
> > remove and re-install apps)
> > - index got not renamed when table got renamed
> > - you cant do a add-column with no default (and other contrains on 
> > table-change where not handled correct
> > - see the cvs-logs for more ;-)
>
>
> Cool!  Glad to see it fixed up.
>
>
> > There is already an existing emulation layer for ADOdb to allow to still 
> > use the phplib calls. Links are in the wiki on the ADOdb page. There is 
> > also a performance comparison.
>
>
> If the emulation layer is a wrapper around ADODB calls, I'd just as soon
> leave it be.  You're introducing more overhead
>
> > The biggest issue I see at the moment with our schema_proc classes 
> > (beside support for other db's, oracle to name one) is the missing index 
> > creation. Only primary keys and unique contrains got created, normal 
> > indices are ignored. This needs to be solved soon and we should use an 
> > update-script to create the indices for the existing installations too.
>
> I can fix that up.  Foreign key support is desirable too.

Cool, go for it.

Agreed.

Wishlist:
- fulltext index for mysql (needed for porting phpbrain)
- the pgsql abstime or mysql timestamp type (we normaly use just int's 
for that purpose), again needed for porting apps
- and transaction support for mysql would be nice too.

I guess, we will find more ;-)

> Really, moving to XML/XSLT for schema proc has huge rewards, as you only
> need to maintain a small schema proc class that executes the transform
> and subsequent SQL in PHP.  The rest can be done in XSLT quite well. 
> I'd much rather write a stylesheet to support a new db (and it's
> abstraction class) than code it into PHP.

I'm not that optimistic about xml for schema proc for 2 reasons:
- we still need to support the "old way" tables_update.inc.php (or do 
you want to port and test all the old scripts ;-)
- the capabilities of the db's are quite different, on some db's we eg. 
rename the table, create a new table with the changed layout, copy the 
whole content and then drop the old one. I dont think we can always 
archiv this with only a style-sheet.

Ralf
--
----------------------------------------------------------------------
Ralf Becker
OUTDOOR UNLIMITED Training GmbH                Telefon 0631 / 31657-0
Leibnizstraße 17                               Telefax 0631 / 31657-26
D-67663 Kaiserslautern            EMail address@hidden