Hi,
It's more like Perl DBI in concept but with a PHP twist; data access
abstraction as opposed to database abstraction.
Is there some source available somewhere? I noticed an ext/pdo on
marcus-boerger.de, with fairly recent code. There is a lot of SQL in the
testset though, so I wouldn't call that data access abstraction. But I
don't really care about a specific name: it is the ability to access
data from multiple backends through one api that interests me.
Although we discussed a limited amount SQL dialect abstraction at
LinuxTag last year, the initial code is not going to do anything about
it.
If the goal is to be able to swap database backends easily, some SQL
abstraction is needed.
If PDO development has settled down after an initial release and you
have time to think about SQL abstraction, I have working code for
sql_escape_string
sql_count
sql_min
sql_max
sql_lowercase
sql_uppercase
sql_concatenate
sql_substring
sql_replace
sql_limit // and offset, except for databases that use TOP as limit
sql_col_alias // use "col AS alias" or "col alias"
sql_tbl_alias
for backends
DBX_ODBC
DBX_MSSQL
DBX_FBSQL
DBX_SYBASECT
DBX_OCI8
DBX_PGSQL
DBX_MYSQL
DBX_SQLITE
I could attach it or put it online somewhere if you wish to take a look.
You'll see more on PDO over the next week, when it starts to appear in
PECL.
Great. What are the initial backends that will be supported? SQLite,
MySQL, PGSQL?
Cheerio, Marc.
Hello Marc,
i'll update the checkout on my server but you will have it through
PECL anyway in a week.
Thursday, May 13, 2004, 5:06:31 PM, you wrote:
Hi,
Although we discussed a limited amount SQL dialect abstraction at
LinuxTag last year, the initial code is not going to do anything about
it.
The main thing we wanted to have is limit. And limit can be emulated
by using a LimitIterator (from ext/SPL). The idea was further more to
have native support for that LimitIterator (somehow somewhen). One
cool way would be to have it automatically generated the LIMIT clause
or what ever is necessary (for example oracle needs other solutions).
If the goal is to be able to swap database backends easily, some SQL
abstraction is needed.
Sure, we plan to have them in PEAR first and see which to move to c code
once they turn out to be stable and nice in sense of handling.
If PDO development has settled down after an initial release and you
have time to think about SQL abstraction, I have working code for
sql_escape_string
sql_count
sql_min
sql_max
sql_lowercase
sql_uppercase
sql_concatenate
sql_substring
sql_replace
sql_limit // and offset, except for databases that use TOP as limit
sql_col_alias // use "col AS alias" or "col alias"
sql_tbl_alias
for backends
DBX_ODBC
DBX_MSSQL
DBX_FBSQL
DBX_SYBASECT
DBX_OCI8
DBX_PGSQL
DBX_MYSQL
DBX_SQLITE
these should go to PEAR/Lukas
I could attach it or put it online somewhere if you wish to take a look.
You'll see more on PDO over the next week, when it starts to appear in
PECL.
Great. What are the initial backends that will be supported? SQLite,
MySQL, PGSQL?
SQLite and Oracle first. We're hoping that the exact two you mentioned
follow very shortly after puttin pdo into pecl.
regards
marcus