[TYPO3-dev] ADOdb vc PDO
Ries van Twisk
typo3 at rvt.dds.nl
Sat May 9 15:09:52 CEST 2009
On May 9, 2009, at 2:22 AM, Jigal van Hemert wrote:
> Hi Ries and others,
>
> Ries van Twisk schreef:
>> AdoDB tries to solve some cross database access issues in a generic
>> way,
>> much like what PDO tries to solve. Both are not trying to solve
>> changing yout queries to something generic.
>
> At the level at which PDO and AdoDB work, they shouldn't change
> queries
> at all.
I Agree, but AdoDB does have some functions to get some generic
functions
to setup for example a LIMIT/OFFSET clause whish differrs from DB to DB,
otehr functions are date handling I believe. These are PHP functions
that translate to teh correct SQL function/clause/code....
I wasn't trying to say it changes SQL, but I was trying to say it has
functions
to solve some problems "AdoDB tries to solve some cross database
access issues in a generic way".
PDO doesn't have this...
> It would be nice to have a db independent abstraction layer in TYPO3,
> but I'm afraid that it's a bit too late for that in 4.x. Thousands of
> extension use their own queries with the low level t3lib_DB functions
> and many may use MySQL specific functions.
>
> To be really db independent the db layer should translate table and
> column definitions from a generic set to db specific definitions.
> The db
> layer should also have to take care of building the actual queries
> based
> on how a specific DBMS stores which type of data.
Well, remember that SQL is a Query Language, you can always settle on
'some' language (or create one)
and then parse that, change it whenever needed and send to correct SQL
to a RDBM.
This is much like what DBAL does, in Java there is JPA that also has a
query langauge that looks
like SQL but isn't SQL.
I have tested some SQL parsers in PHP and they all suck badly, so
apparently in PHP it's not easy to parse queries,
DBAL also has it's issues, but currently there is some work in this
area.
>
> Trying to interpret a query and rebuild it for another DBMS seems to
> be
> a very ambitious project.
Yup... but not impossible...
>
>> 1) AdoDB was there way before PDO, keep that in mind.
> Historic reasons were also mentioned by others; good point!
>
>> 2) PDO is not fully stable yet and not well field tested!
> Hmm... it's been around for many years. With the fact in mind that
> many 'standard' extensions of TYPO3 are still in beta after so many
> years, I can understand this ;-)
>
>> 3) AdoDB does have some utils to store schema's in XML, so they can
>> be transparently
> A DBMS independent way to store schema information would be nice.
> Way better than the ext_tables.sql stuff...
>
>> 4) PDO cannot be found on a lot of PHP installations yet
> I think it's there on most PHP5 installations. The PHP manual says
> about installing PDO: "If you're running a PHP 5.1 release, PDO and
> PDO_SQLITE is included in the distribution; it will be automatically
> enabled when you run configure."
> So any hoster who runs a standard PHP5 installation seems to have
> PDO enabled.
Yeaa but you also need other PDO versions like MySQL, PostgreSQL and
others... often this needs to be manually compiled through PCL (or was
it pear...)
>
>> 5) PDO will properly be a bit fatser then AdoDB because AdoDB is
>> written in PHP itself, I think PDO can send prepared statements to
>> the server and AdoDB does that work 'in house' (as far as I know,
>> may be that is changed).
>
> PDO uses the specific drivers for this. If the DBMS doesn't support
> certain features of PDO they will be emulated.
>
> Regarding security in TYPO3, it would be great to use the parameter
> binding options in PDO (which may also be present in AdoDB). No more
> SQL injections :-)
>
>> 6) Note for 5) AdoDB is also available as a PHP extension.... I
>> never tried it
>
> It will probably be faster than the PHP version. Then again, it will
> not be present in most PHP installations by default.
Agreed, but the same goes for PDO... I remember when I made my PDO
version of TYPO3_DB I had to compile PDO for MySQL and PostgreSQL
MySQL and
it didn't came with my installation (OSX).
I would go for PDO any time today though....
>
>> 7) AdoDB also has Active Record... PDO has none of that
>
> PDO only has a very rudimentary PDOStatement->fetchObject to
> retrieve the next record as an object. Indeed it doesn't have a
> whole mapping of the data to a series of object with the possibility
> to change the data in the database using those objects.
> I've never felt the need for this however.
I feel the same,... some people swear by ORM models but the work I
have recently be doing didn't fit a ORM model so I never bothered to
look into ORM. JPA (Java) does have some really nice
features in that area though... Not sure if similar is available for
PHP, properly not because PHP doesn't have strong support for
annotations..
>
> Thanks to all who replied! It really gave me a good impression of
> why AdoDB is being used.
Your welcome....
>
> Regards,
>
> --
> Jigal van Hemert.
> _______________________________________________
> TYPO3-dev mailing list
> TYPO3-dev at lists.netfielders.de
> http://lists.netfielders.de/cgi-bin/mailman/listinfo/typo3-dev
regards, Ries van Twisk
-------------------------------------------------------------------------------------------------
Ries van Twisk
tags: Freelance TYPO3 Glassfish JasperReports JasperETL Flex Blaze-DS
WebORB PostgreSQL DB-Architect
email: ries at vantwisk.nl
web: http://www.rvantwisk.nl/
skype: callto://r.vantwisk
Phone: +1-810-476-4196
SIP: +1-747-690-5133
regards, Ries van Twisk
-------------------------------------------------------------------------------------------------
Ries van Twisk
tags: Freelance TYPO3 Glassfish JasperReports JasperETL Flex Blaze-DS
WebORB PostgreSQL DB-Architect
email: ries at vantwisk.nl
web: http://www.rvantwisk.nl/
skype: callto://r.vantwisk
Phone: +1-810-476-4196
SIP: +1-747-690-5133
More information about the TYPO3-dev
mailing list