Re: Re: DataObject compatibility
| From: | Markus Wolff | Date: | Fri, 27 Jun 2003 09:02:51 +0000 |
| Subject: | Re: Re: DataObject compatibility | ||
| References: | 1 2 | Groups: | php.pear.general |
| Request: | Send a blank email to pear-general+get-6277@lists.php.net to get a copy of this message | ||
Alan Knowles wrote:
Hi Alan, I´ve tried it with MySQL yesterday and with MSSQL today - generating the classes and the schema file worked like a charm on both databases. When doing it for MSSQL, the generator script threw quite a few warnings, but other than that, there were no problems. Cool ;-)1. Has it been tested with other databases than MySQL? I need support for at least Microsoft SQL Server as well. Postgres and Oracle would be neat, too ;-)I've heard stories of MSSQL/Oracle useage, as some bugs in DB where picked up by the Generator.
limit(), will issue a pear:error on mssql & oracle, as the limit emulation for this is a little complex.If I understand the code right, all I need to do is add the modifyLimitQuery() method to PEAR::DB´s MSSQL driver class to make it work, is that correct? If so, I think I know a way to make limit() work with MSSQL as well.
I'm using it on a major project on Postgres at the moment - hence, there have been a number of fixes in the last few versions to assit with postgres support.Speaking of large projects - I have some applications that are subdivided into modules and plugins, each having their own directory structure - but still, they´re interacting with each other quite heavily. Is there a possibility to tell the autogenerator just to pick some specific tables that belong to my current module/plugin out of the database, instead of always generating classes for all the tables? Also, can I import more than one config and schema file when I dynamically include other modules/plugins that have their class and schema files in different directories?
2. Is it possible to add class properties that are not treated as table fields? I often like to have getGrid(), getForm() etc. methods that use a common template object that is stored in a property, like: [...]
as long as they dont overlap the table field names, they should be ignored in general. I do this alot, - tricks like overriding fetch, to do some extra calculation.. etc. is quite nice..It is indeed, I´ve demonstrated the package to some folks at work here today, and when I ran the generator and showed the output, several jaws dropped to the ground ;-) CU Markus