I was wondering if you eventually plan to include support for other Databases? Maybe via PEAR database abstraction?
I ask because I really need the features of PostgreSQL, which aren't present in MySQL...
Thanks!
--phil
henk
2005-08-11 12:47:48
Hi Pheller,
I was planning to send you a message, but did not yet come to it. I see that you already found it yourself.
With respect to postgreSQL: i have no concrete plans for that. Maybe you can try it yourself: If its SQL is much lyke MySQL, you only have to refactor PntQueryHandler so that it gets subclasses for specific databases. Then implement the necessary plumming to het queries executed and error info back on each subclass. PEAR may make that easier, but native php database functions do not seem very complicated either.
The real problem lays in the incompatibilities between SQL implementations of different databases. Currently the framework does a lot of SQL generation directly from pnt.db.query.PntSqlSpec subclasses. These subclasses will have to delegate a lot of SQL generation to the QueryHandler to make the right SLQ for the target database platform. As far as i know PEAR does not convert SQL queries to run on different databases, so it's value seems primarily that it can access more database then php itself. Please correct me if i am wrong.
IMHO a downside of PEAR is its install procedure, it seems uncecessary complex and not to be fit for shared hosting accounts (unless you are the hositing service provider). Furthermore, we can not include PEAR classes because we use php in the name of the framework (see the php license). So my choice would be to avoid PEAR if possible, or otherwise (if it is worht the trouble) make its use optional.
Then there is one remark on the 1.2 alpha: I wrote elsewhere on this forum that the implementation of N to M relationships is still a little ugly. One ugly thing in particular is that it does not properly delegate it's SQL generation. So in its current state it will be hard for you to handle eventual SQL incompatibilities (here you see the framework is really developed incrementally. Your advantage is that you can already use it, your disadvantage is that it is not yet as flexible as the rest of the framework). I certainly want to get this fixed to the extent that it no longer breaches the frameworks database abstraction architecture, but once again, i can make no promises with respect to the schedule.
Greetings,
Henk Verhoeven.
pkellner
2005-08-13 00:53:20
I'm curious what features you are looking for. I just went through the same thing and am using mysql 5 while having some issues. I really don't like the "vacuuming" in postgres. I think the new Mysql transaction stuff is much more "oracle" like and probably will be more scalable.
pheller
2005-08-15 05:57:29
I'm specifically looking for the IP address data types and associated functions, as well as pl/perl.
Add a Reply
Loading form, please wait
The website will not send you an e-mail when a reply is added to this topic
Glad to see the M-to-N component available now.
I was wondering if you eventually plan to include support for other Databases? Maybe via PEAR database abstraction?
I ask because I really need the features of PostgreSQL, which aren't present in MySQL...
Thanks!
--phil
I was planning to send you a message, but did not yet come to it. I see that you already found it yourself.
With respect to postgreSQL: i have no concrete plans for that. Maybe you can try it yourself: If its SQL is much lyke MySQL, you only have to refactor PntQueryHandler so that it gets subclasses for specific databases. Then implement the necessary plumming to het queries executed and error info back on each subclass. PEAR may make that easier, but native php database functions do not seem very complicated either.
The real problem lays in the incompatibilities between SQL implementations of different databases. Currently the framework does a lot of SQL generation directly from pnt.db.query.PntSqlSpec subclasses. These subclasses will have to delegate a lot of SQL generation to the QueryHandler to make the right SLQ for the target database platform. As far as i know PEAR does not convert SQL queries to run on different databases, so it's value seems primarily that it can access more database then php itself. Please correct me if i am wrong.
IMHO a downside of PEAR is its install procedure, it seems uncecessary complex and not to be fit for shared hosting accounts (unless you are the hositing service provider). Furthermore, we can not include PEAR classes because we use php in the name of the framework (see the php license). So my choice would be to avoid PEAR if possible, or otherwise (if it is worht the trouble) make its use optional.
Then there is one remark on the 1.2 alpha: I wrote elsewhere on this forum that the implementation of N to M relationships is still a little ugly. One ugly thing in particular is that it does not properly delegate it's SQL generation. So in its current state it will be hard for you to handle eventual SQL incompatibilities (here you see the framework is really developed incrementally. Your advantage is that you can already use it, your disadvantage is that it is not yet as flexible as the rest of the framework). I certainly want to get this fixed to the extent that it no longer breaches the frameworks database abstraction architecture, but once again, i can make no promises with respect to the schedule.
Greetings,
Henk Verhoeven.