Page 1 of 1
Database abstraction layer - OOP style w. pagination support
Posted: Thu Feb 16, 2006 2:39 am
by raul
I’ve started a project for database abstraction layer with full pagination support for SQLite, MySQL, MSSQL and PostgreSQL.
The project can be founded at:
SourceForge
With a little delay, the project will be founded also on following sites:
PHP Classes
PHP Builder (as a ZIP archive)
Hot Scripts
CodeWalkers
Planet Source Code
Tigris
I would be very interested about your opinions.
Best regards,
Raul
Posted: Thu Feb 16, 2006 2:56 am
by feyd
What's the advantage of this over, say ADOdb?
Posted: Thu Feb 16, 2006 2:59 am
by raul
Posted: Thu Feb 16, 2006 3:18 am
by Christopher
It looks like you have done an immense amount of excellent work. It looks a lot like PDO -- which is not a bad thing -- but why use yours when there is PDO? You would say because of the build in pagination, but I think design-wise database access, paging calculation, request processing and HTML generation really should not be combined if you believe in
separation of concerns.
TimVW and I have had a conversation about Pagers and have gone the opposite direction by separating out the various functionality into separate classes here
viewtopic.php?t=43777.
Posted: Thu Feb 16, 2006 4:05 am
by raul
I don’t know for sure, but to be honest, I’ve start this project based on my own needs because it would be easier for me to debug something I’ve made than to learn to use something else

…even if this means to reinvent the wheel, probably.
During the development I’ve wondered if this would be useful to other people , also…..and this would be anyway, the best method to find bugs, errors…and so on…..
And regarding "separation of concerns"...well, I'm not a fun of it.....

Posted: Thu Feb 16, 2006 11:49 am
by timvw
I don't have a local adodb installation available to verify it right now, but i'm pretty sure their paginator uses SelectLimit, which in turn uses for most drivers the limit/top/whatever dialect for limiting a resultset statement...
Posted: Fri Feb 17, 2006 1:16 am
by raul
Code: Select all
<?PHP
$sql="select id, data from test order by id asc";
//-----------------------------------------------------------------------
$cn = new COM("ADODB.Connection");
$cn->ConnectionTimeout=0;
$cn->CommandTimeout=0;
$cn->CursorLocation=3;//adUseClient
$cn->Mode=1;//connection mode: Read
//mysql
$cn->ConnectionString="Provider=MSDASQL.1;DRIVER=MySQL ODBC 3.51 Driver;Persist Security Info=False;UID=root;PASSWORD=MyPassword;DATABASE=test;SERVER=localhost;OPTION=2056";
//MSSQL->"Provider=SQLOLEDB.1;Persist Security Info=False;User ID=sa;Password=MyPassword;Initial Catalog=pubs;Data Source=localhost"
$cn->Open();
//-----------------------------------------------------------------------
$cmd=new COM("ADODB.Command");
$cmd->CommandText=$sql;
$cmd->ActiveConnection=$cn;
$cmd->Execute();
//-----------------------------------------------------------------------
$rs=new COM("ADODB.Recordset");
$rs->CacheSize=1024;
$rs->CursorType=2;//dynamic
$rs->CursorLocation=3;//use client
$rs->LockType=1;//read-only
$rs->Open($cmd);
$rs->PageSize=9;
$pages=$rs->PageCount;
$rs->AbsolutePage=2;
print "Pages $pages\r\n\r\n";
//-----------------------------------------------------------------------
$num_columns = $rs->Fields->Count();
//echo $num_columns . "\n";
while ((!$rs->EOF) && ($rs->AbsolutePage==2))
{
print $rs->Fields(0)->Value." ".$rs->Fields(1)->Value."\r\n";
$rs->MoveNext();
}
$rs->Close();
$cn->Close();
$rs = null;
$cmd=null;
$cn = null;
?>
Well when the code is
Code: Select all
while ((!$rs->EOF) && ($rs->AbsolutePage==2))
isn't it that the a large part of recordset is sent to the client and is client's job to skip unwanted rows? (E.G.
)
I'm not a fun of ADODB and this is not the subject in here.
What I am interested of is your opinions (any kind) regarding my project....
Posted: Fri Feb 17, 2006 1:39 am
by Christopher
raul wrote:I don’t know for sure, but to be honest, I’ve start this project based on my own needs because it would be easier for me to debug something I’ve made than to learn to use something else

…even if this means to reinvent the wheel, probably.
During the development I’ve wondered if this would be useful to other people , also…..and this would be anyway, the best method to find bugs, errors…and so on…..
By your own logic, other people would not be interested in your code because it would be easier for them to debug something they’ve made than to learn to use yours.
Posted: Fri Feb 17, 2006 1:43 am
by raul
arborint wrote:By your own logic, other people would not be interested in your code because it would be easier for them to debug something they’ve made than to learn to use yours.
Well maybe you are right...but this doesn’t exclude the possibility that someone would give me some feedback regarding project.
In fact, the base idea is helping each other…isn’t it?
I’m not saying: “
Use my solution!”
(but if you want to, I’ll give you my full support
).
Instead I’m searching for some feedback……
Posted: Fri Feb 17, 2006 10:13 am
by timvw
I was talking about this
ADODB...
Posted: Fri Feb 17, 2006 2:18 pm
by raul
Oh

, well...anyway I suppose is a little different implementation of ADO than my previous example and
I don't like ADO within any inplementation.
I don't wanna be rude but ADODB is not the subject in this thread.
I’m just searching for some feedback regarding my project…… 
That’s all what I’m asking for! 
Thanks.
another alternative
Posted: Tue Feb 21, 2006 10:14 pm
by cknudsen
I recently took the db abstraction code out of my WebCalendar project and created a new project on SourceForge:
http://www.k5n.us/dbi4php.php
I doubt many people will find it as useful for ADOdb. My dbi4php implementation comes in under 700 lines of code

The code started in 1999 (when I started WebCalendar), long before PEAR and (I think) before ADOdb. I looked at ADOdb for WebCalendar a few times, but it's just too much. For an open source app that was 200k, I couldn't see doubling (or more) the downlaod size just for a db abstraction layer. We looked at it again recently, but it's still more code than I need.
So, I can understand why you started your own db abstraction tool. There's nothing that fits as well as something you've written yourself

Re: another alternative
Posted: Thu Feb 23, 2006 1:28 am
by raul
cknudsen wrote:...So, I can understand why you started your own db abstraction tool. There's nothing that fits as well as something you've written yourself

It seems that I’m not the only one who thinks that way!!!

Posted: Tue May 23, 2006 1:32 pm
by raul
To compare my little project with other DALs it is a little unpossible because:
ADOdb - I'll never be a fun of ADO especially that it is NOT implemented using OOP facilities of PHP 5.
PEAR:: DB (or DBX) - it seems to bloated for me ant it is like someone will try to kill a fly with an atomic bomb!
PDO - it seems to be promising and I've inspired a little from it's logic.
Zend Framework - I don't have anything to say in here...........it is not alpha stage, at least....
So, if any of you is wiiling to help me by giving me some suggestions, critics and so on, it will be highly appreciated!

Posted: Fri May 26, 2006 3:16 pm
by raul
Now
THE PROJECT IS RELEASED UNDER MIT LICENSE and it is 99.99% bug-free!!!
So if any of you find a bug I will high appreciate your submission!
