Re: [PHP-DEV] Advice on design issues (long)...

[l0t3k]

"Lukas Smith" <[EMAIL PROTECTED]> wrote in message
008a01c1d2fb$952b4630$4d00a8c0@vandal">news:008a01c1d2fb$952b4630$4d00a8c0@vandal...
>
> There is currently an effort underway to merge Metabase with PEAR DB.
> I have just commited the first code into the pear cvs (package is called
> "MDB" for now). The merge is still not complete. But the idea was that
> this merged DB abstraction layer could down the road be ported to C ...
> the sooner the better.
ive downloaded alreay. i keep track of development of PEAR::DB, Metabase and
ADOdb.


> In terms of how to abstract things, its quite obvious that Metabase is
> very far ahead (is there even something similar in other languages?). So
> I guess Metabase, or MDB when its ready, will be the best place to turn
> to if you seek this knowledge for a C Extension.
the abstraction work is primarily done, the blob spec is the main thing
pending. the hard part now is producing a set of test drivers.

> Anyways if you are interested then you may want to join the discussion
> on this new package. All discussion goes to the binarycloud, metabase
> and pear-dev mailinglists, since there is no dedicated mailinglist for
> this project, but all of the above the mailinglists are participating.
im an active lurker on the binarycloud and metabase lists. i throw my $0.02
in periodically.

l0t3k




-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Advice on design issues (long)...

[l0t3k]

"John Lim" <[EMAIL PROTECTED]> wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...

> I have always wondered, how do you pronounce L0t3k?
actually "low-tech". most days i dream of woodworking 

> Seriously, if you are duplicating Metabase's effort, but in C,
> why not work with the Manuel Lemos then? This will fix any speed issues
> that Metabase has, and you will get his feedback.
the DB abstraction problem is a much larger one, which Manuel (and yourself)
have been struggling against with serious handicaps. for instance, one of
the reasons Manuel had to put so much work into Metabase is that the
original extension writers did not provide metadata which is readily
available from the database itself, or the metadata supplied is inconsistent
across back-ends.

the current database extensions were written as needed, so there was no
over-arching and unifiying design.
im attempting to consolidate and refactor the code in the existing
extensions into a framework which makes driver development much easier and a
lot more flexible. the upshot is that features can be implemented in the
core that
are immediately available across DB backends (like disconnected resultsets,
resultset serialization, and XML import/export which is nearly done).  in
addition, features like connection management can be handled consistently
across supported backends.

> Many db abstraction classes I have seen are skewed towards
mysql/postgresql,
> so prove to be useless when migrating to mssql or oracle.
ive done quite a lot of legwork on this, and i think i have a framework
which accomodates everything from MySQL to Oracle. i did MySQL first because
1) the API is simple 2) i needed to quickly write a driver to test some
basic design decisions (navigation and bulk-fetching).

>Manuel really
> knows a lot about databases and can teach everyone a lot about these
issues.
>
> Or if you or anyone else would like to port ADOdb to a C extension,
> let me know.
i actually wrote to Manuel about this last summer, but he was (justifiably)
skeptical about the doability of the project and the prospects of its
adoption, given its scope and the fact that most people were comfortably
either using the base extensions, or something like Metabase, PEAR or ADODB.
instead of long discussions, i decided to wait until i had something
tangible to demonstrate. im very near to that point right now.

note that i dont think that Metabase or ADOdb will necessarily go away if
this extension works out. there are things that you and Manuel do that i
think belong in user-space and not in an extension. for instance your
sequence emulation code modifies the DB schema, which crosses the line of an
access layer. also Manuel's schema abstraction and transformation is another
example. i only really care at this point about data and metadata acess
abstraction. what it means though, is that your PHP code will be
considerably smaller and faster ( i think i can eliminate the need for at
least 65% of Metabase's code).

l0t3k



-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] Advice on design issues (long)...

[Lukas Smith]

> (2) im working on a database access abstraction, again inspired by
Java
> and
> JDBC (MySQL driver is written and works, BTW). in Java you have the
> Resultset.getXXX methods which gets the value of a given column as a
> particular type. Java of course is strongly typed, whereas PHP is not.
Is
> it
> useful to implement the getXXX methods natively. i lean toward it
> primarily
> because 1) folks coming from Java will be right at home 2) sometimes
you
> need to enforce a particular return type coming from a column 3)
Metabase
> does it for portability, and although it can be done in PHP, its more
> efficient to do it in the extension. On the downside there is the
issue of
> bloat.

There is currently an effort underway to merge Metabase with PEAR DB.
I have just commited the first code into the pear cvs (package is called
"MDB" for now). The merge is still not complete. But the idea was that
this merged DB abstraction layer could down the road be ported to C ...
the sooner the better.

In terms of how to abstract things, its quite obvious that Metabase is
very far ahead (is there even something similar in other languages?). So
I guess Metabase, or MDB when its ready, will be the best place to turn
to if you seek this knowledge for a C Extension.

Anyways if you are interested then you may want to join the discussion
on this new package. All discussion goes to the binarycloud, metabase
and pear-dev mailinglists, since there is no dedicated mailinglist for
this project, but all of the above the mailinglists are participating.

Best regards,
Lukas Smith
[EMAIL PROTECTED]
___
 DybNet Internet Solutions GbR
 Alt Moabit 89
 10559 Berlin
 Germany
 Tel. : +49 30 83 22 50 00
 Fax : +49 30 83 22 50 07
 www.dybnet.de [EMAIL PROTECTED]
___



-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Advice on design issues (long)...

[John Lim]

L0t3k <[EMAIL PROTECTED]> wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> im looking for opinions on two OOP related design issues for code im
> targeting to PHP5.
> (2) im working on a database access abstraction, again inspired by Java
and
> JDBC (MySQL driver is written and works, BTW). in Java you have the
> Resultset.getXXX methods which gets the value of a given column as a
> particular type. Java of course is strongly typed, whereas PHP is not. Is
it
> useful to implement the getXXX methods natively. i lean toward it
primarily
> because 1) folks coming from Java will be right at home 2) sometimes you
> need to enforce a particular return type coming from a column 3) Metabase
> does it for portability, and although it can be done in PHP, its more
> efficient to do it in the extension. On the downside there is the issue of
> bloat.

Hi,

I have always wondered, how do you pronounce L0t3k?

Seriously, if you are duplicating Metabase's effort, but in C,
why not work with the Manuel Lemos then? This will fix any speed issues
that Metabase has, and you will get his feedback.

Many db abstraction classes I have seen are skewed towards mysql/postgresql,
so prove to be useless when migrating to mssql or oracle. Manuel really
knows a lot about databases and can teach everyone a lot about these issues.

Or if you or anyone else would like to port ADOdb to a C extension,
let me know.

Regards, John



-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Advice on design issues (long)...

[l0t3k]

im looking for opinions on two OOP related design issues for code im
targeting to PHP5.

(1) im writing (actually porting) a DateTime class which matches the
functionality of the Java Date class. it actually does much more, and that's
the issue. in looking at the Javadocs reference page for Date, a lot of what
i have scheduled for my class has been deprecated in Date for various
reasons. in specific, display formatting, parsing and interval math are
moved into other classes.
what do you think about having this functionality in one class or
splitting. i agree somewhat in a separation of concerns, but one reason i
tend not to like Java for web development is the fact that there can be too
many classes involved in getting basic things accomplished.

(2) im working on a database access abstraction, again inspired by Java and
JDBC (MySQL driver is written and works, BTW). in Java you have the
Resultset.getXXX methods which gets the value of a given column as a
particular type. Java of course is strongly typed, whereas PHP is not. Is it
useful to implement the getXXX methods natively. i lean toward it primarily
because 1) folks coming from Java will be right at home 2) sometimes you
need to enforce a particular return type coming from a column 3) Metabase
does it for portability, and although it can be done in PHP, its more
efficient to do it in the extension. On the downside there is the issue of
bloat.


BTW : is there sufficient interest in starting a new newsgroup to discuss
PHP5 ?

l0t3k



-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php