Electronics & Programming

develissimo

Open Source electronics development and programming

  • You are not logged in.
  • Root
  • » PHP
  • » [PHP-DEV] google SoC - dbobj [RSS Feed]

#1 March 17, 2007 12:28:48

Bankó Á.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

[PHP-DEV] google SoC - dbobj


Hi!

I'm an interested student with a project idea for the PHP.net Google
Summer of Code.

I'm thinking about a native ( compiled from C ) ORM extension for PHP. I
don't need to explain how useful and important it is in modern web
applications / frameworks.

My goal is a native php extension that
- is efficient / high performance (thanks to good application design
and native code)
- has a really good API (thanks to PHP5's extensible object modell)
- works with all major DBMSs (by using PDO)
- is flexible, so with thin wrapper classes it could be a drop-in
replacement for any framework's ORM module.

The concept is object persistence (somewhat similar to Hibernate for
Java). I think object persistence is the most simple, clean and usable
ORM concept, however it is the hardest to implement especially in pure
PHP code (no access to PHP5's internal object modell).

So what do you think? Is it a good project for SoC?

About me: I'm 19 year old, a student at the Budapest University of
Technology and Economics on the IT department ... and as you have
already discovered, not a native English speaker.

Adam Banko

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

Offline

#2 March 17, 2007 13:42:57

Marcus B.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

[PHP-DEV] google SoC - dbobj


Hello Bankó,

sounds good to me. Can somone please add this to the ideas page while I am
travelling? And you can make yourself already familiar with the GSoC and
file all information you can already.

best regards
marcus

Saturday, March 17, 2007, 1:28:08 PM, you wrote:

> Hi!

> I'm an interested student with a project idea for the PHP.net Google
> Summer of Code.

> I'm thinking about a native ( compiled from C ) ORM extension for PHP. I
> don't need to explain how useful and important it is in modern web
> applications / frameworks.

> My goal is a native php extension that
> - is efficient / high performance (thanks to good application design
> and native code)
> - has a really good API (thanks to PHP5's extensible object modell)
> - works with all major DBMSs (by using PDO)
> - is flexible, so with thin wrapper classes it could be a drop-in
> replacement for any framework's ORM module.

> The concept is object persistence (somewhat similar to Hibernate for
> Java). I think object persistence is the most simple, clean and usable
> ORM concept, however it is the hardest to implement especially in pure
> PHP code (no access to PHP5's internal object modell).

> So what do you think? Is it a good project for SoC?

> About me: I'm 19 year old, a student at the Budapest University of
> Technology and Economics on the IT department ... and as you have
> already discovered, not a native English speaker.

> Adam Banko




Best regards,
Marcus

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

Offline

#3 March 17, 2007 23:07:56

Lukas K.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

[PHP-DEV] google SoC - dbobj


Bankó Ádám wrote:I'm an interested student with a project idea for the PHP.net Google
Summer of Code.

I'm thinking about a native ( compiled from C ) ORM extension for PHP. I
don't need to explain how useful and important it is in modern web
applications / frameworks.IMHO a full ORM belongs into user space and not into C code. I kind oflike the approach that ADODB did, which was taking an existing DBAL andmoving selected items that where bottlenecks into C space. Therebyproviding a drop in speed improvement, while keeping the C code to aminimum.As such I would prefer that this would be done in collaboration with anexisting or in development PHP ORM.I recently opened a mailing list on exactly the top of databaseabstraction in PHP that already has well over 30 subscribers and prettymuch all of the key ORM developers in the PHP space:http://pooteeweet.org/blog/611Might be a good idea to bring up your thoughts there as well and see ifthere is a chance for collaboration with an existing userland ORM project.regards,
Lukas

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

Offline

#4 March 18, 2007 15:31:15

Bankó Á.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

[PHP-DEV] google SoC - dbobj


Hi!

First a small abstract:
Lukas suggested that a full ORM shouldn't be implemented in C. The short
reply is that I think that core ORM features could be implemented in C,
and that would be good.

Why? Read the rest..

I've looked into the phpdbabstraction list you liked and I think it's a
brilliant idea. I'm sure it'll generate a lot of innovation, and help
make the "PHP ORM world" better :)

I'll write to the list when I've gathered my thoughts, but for the time
I'll keep the main discussion here. This list is broader, and I'm
interested in the opinion of other, not only ORM developers.

Now, for some real issues. You said you think that "a full ORM belongs
into user space and not into C code". I'm thinking about pros and cons,
first for pure PHP and pure C implementation.

Pure PHP code is easier to write, easier to debug, and easier to
maintain than C code. So more and better features can be implemented in
less time.

Pure C code has access to PHP5's low level object API, so it can produce
a really intuitive interface (object persistence), that you can't do
from PHP code. C code uses a bit less memory and a lot less CPU time
(accessing a member in a struct vs. accessing a member in a PHP array).
A native extension can cache lot of hard-to-generate data in the process
memory (that doesn't get destroyed after requests).

So, the straight conclusion is that we should have hybrid solution, that
has the strengths of both words. The arising question is where to draw
the line?

>From what you have written, I think you are suggesting to keep C code
minimal. I can imagine that in the following way: There is this
extension and the userspace application registers hooks on it, so it has
access to the interface benefits of the internal object model. This
more-or-less solved the outer interface problem, but generated a bigger
problem, PHP's internal interface is not ment to be used by user
scripts, and mixing the normal and this direct OO API would result in an
over-complicated and hard to maintain code.

The __get and __set methods create some magical behavior, but for this
we'd need a lot of magic, and we know magic don't scale well.

The other issue is performance. For the ORM field I didn't find
operation that could be moved out to native code efficiently. Most
complex operations need a lot of data, and passing this data to a native
function, doing decoding and after it's processed the time needed for
recoding would eliminate the performance benefit. For example ADODB
could implement the resultset_to_array method in C, because there's
minimal overhead on fetching a row from a database resource (negative
compared to it's PHP equivalent).

This isn't gonna work well. We need something different. And this the
solution I'm suggesting.

Let there be defined a small set of features that all ORM should have.
This is what most people use most of the time. Let's implement this set
of features in native code, and make it very flexible and extensible, so
other features could be added to it from PHP code. This solution
performs nicely for common tasks, but could also have many - not so
commonly used - fancy features implemented in PHP. Of course these extra
features won't be as fast as the rest, but this way special needs could
also be addressed.

So the frequently used features are fast, and the less-used features are
slow, but there these extra features are easy to implement. I think this
is good.

And one more point. In C you can implement complex object oriented
structures (lot of classes with fancy virtual functions) with small
overhead, while in PHP this structure could mean a lot of overhead. For
example separate class for every column type, and separate object for
every persistent value is unimaginable in PHP, but sounds OK in C. This
means that although managing PHP code should be easier than managing C
code, thanks to the stronger structure in C, in the end it could turn
out to be just as manageable as it's imagined PHP equivalent.

And as conclusion, some pseudo code, I'd like to see working:

//class Person {DB mapping options, constructor, ...}
$a = new Person("Lukas"); // create new record
$a->fiend = $f = Person::get(15); // setting an FK field
$b = Person::get(15); //won't load it again, reference it (singleton)
//update $f == $b 's age, and set the modified bit on this field
$a->friend->age++;
//no explicit save, implicit save on destruction

Thanks for your attention, Adam


2007. 03. 18, vasárnap keltezéssel 01.07-kor Lukas Kahwe Smith ezt írta:
> Bankó Ádám wrote:
>
> > I'm an interested student with a project idea for the PHP.net Google
> > Summer of Code.
> >
> > I'm thinking about a native ( compiled from C ) ORM extension for PHP. I
> > don't need to explain how useful and important it is in modern web
> > applications / frameworks.
>
> IMHO a full ORM belongs into user space and not into C code. I kind of
> like the approach that ADODB did, which was taking an existing DBAL and
> moving selected items that where bottlenecks into C space. Thereby
> providing a drop in speed improvement, while keeping the C code to a
> minimum.
>
> As such I would prefer that this would be done in collaboration with an
> existing or in development PHP ORM.
>
> I recently opened a mailing list on exactly the top of database
> abstraction in PHP that already has well over 30 subscribers and pretty
> much all of the key ORM developers in the PHP space:
>http://pooteeweet.org/blog/611>
> Might be a good idea to bring up your thoughts there as well and see if
> there is a chance for collaboration with an existing userland ORM project.
>
> regards,
> Lukas

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

Offline

#5 March 18, 2007 15:40:24

Lukas K.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

[PHP-DEV] google SoC - dbobj


Bankó Ádám wrote:Pure C code has access to PHP5's low level object API, so it can produce
a really intuitive interface (object persistence), that you can't do
from PHP code. C code uses a bit less memory and a lot less CPU timeI would hope that the solution for "low level object API" would be thatwe expose more and more of that to user space. Stuff like being able toforce the calling of the parent constructor come to mind, I am surethere are other things more relevant to the topic at hand as well. Butyes, its a valid point.The other issue is performance. For the ORM field I didn't find
operation that could be moved out to native code efficiently. Most
complex operations need a lot of data, and passing this data to a native
function, doing decoding and after it's processed the time needed for
recoding would eliminate the performance benefit. For example ADODB
could implement the resultset_to_array method in C, because there's
minimal overhead on fetching a row from a database resource (negative
compared to it's PHP equivalent).Yeah, you are right .. it might be hard to find things that can be movedto C space and vice versa. I do not know where to draw the line thisvery second either. I just want to make sure that this option is explored.I remember that Thies once said, the ultimate goal of the PHP languagewould be to make everything fast enough in PHP so that everything can bedone in user space. All the extension should do is expose third partylibs. Of course this might only be a dream, but I think its one of thosedreams worth purseing .. even if you never make it.regards,
Lukas

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

Offline

#6 March 18, 2007 16:22:20

Bankó Á.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

[PHP-DEV] google SoC - dbobj


> I remember that Thies once said, the ultimate goal of the PHP language
> would be to make everything fast enough in PHP so that everything can be
> done in user space. All the extension should do is expose third party
> libs. Of course this might only be a dream, but I think its one of those
> dreams worth purseing .. even if you never make it.

I'm thinking about if PHP was fast, and extensions were only exposing
library interfaces, then PHP would be C/C++/Java/etc.

In my opinion - in every language - low level stuff should be
implemented efficiently (with low level tools), so the things building
on it can perform.

In the beginning, database API usage was an important part of most PHP
applications. Then came the smart/thin DB abstraction layers, and the
database access API was wrapped to be a bit nicer and more-or-less
database independent. Now the topic is ORM, that wraps all database
related things, to provide a nice OO interface. And further, these ORM
solutions are only a small part of the modern web development
frameworks.

These are a lot of layers, and I think we should reconsider what is
low-level and what is not. Some years ago ORM was by no means low-level.
But as things are getting more complex, I think we could say, that ORM
is a low-level building block of the near-future's web applications.

Adam

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

Offline

#7 March 18, 2007 16:23:52

Lukas K.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

[PHP-DEV] google SoC - dbobj


Hi,

just to clarify .. from your comments I am quite hopeful in your proposal.

regards,
Lukas

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

Offline

#8 March 19, 2007 13:52:30

Tony B.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

[PHP-DEV] google SoC - dbobj


Lukas Kahwe Smith wrote:IMHO a full ORM belongs into user space and not into C code. I kind oflike the approach that ADODB did, which was taking an existing DBAL andmoving selected items that where bottlenecks into C space. Therebyproviding a drop in speed improvement, while keeping the C code to aminimum.I agree. I'm a user of Propel (http://propel.phpdb.org) which is in theuser space as you suggest and I think it works fine. The current betaversion of Propel uses PDO so execution speed isn't really a hugeproblem. I think the only thing worth considering adding to the C-codeis something to compliment PDO that can collect all the databasemetadata that ORM's require. Propel currently does this using Creole(one of the many DB abstraction libraries out there).As such I would prefer that this would be done in collaboration with anexisting or in development PHP ORM.Again, I agree. And being a bit biased I'd simply like to throw Propelinto the mix for consideration.--Tony

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

Offline

#9 March 19, 2007 13:57:22

Lukas K.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

[PHP-DEV] google SoC - dbobj


Tony Bibbs wrote:I agree. I'm a user of Propel (http://propel.phpdb.org) which is in theuser space as you suggest and I think it works fine. The current betaversion of Propel uses PDO so execution speed isn't really a hugeFYI: You are mistaken if you think that moving from the old extensionsto PDO provides a speed improvement (there is rather decrease unless youare using fetchAll()).problem. I think the only thing worth considering adding to the C-codeis something to compliment PDO that can collect all the databasemetadata that ORM's require. Propel currently does this using CreoleAnd this imho is the thing that should definitely stay in userland. Itsa giant hackery to get it to work. This is something people need to beable to adapt quickly. Putting this in C would be a maintenance nightmare.regards,
Lukas

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

Offline

#10 March 19, 2007 14:02:15

Tony B.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

[PHP-DEV] google SoC - dbobj


Lukas Kahwe Smith wrote:FYI: You are mistaken if you think that moving from the old extensionsto PDO provides a speed improvement (there is rather decrease unless youare using fetchAll()).Sorry, I wasn't clear on this. Creole is the DB abstraction layer on topof the "old extensions". The older versions of Propel were implementedthat way. The new beta version uses PDO dicrectly (i.e. minus Creole)and that showed significant speed improvements over prior versions.And this imho is the thing that should definitely stay in userland. Itsa giant hackery to get it to work. This is something people need to beable to adapt quickly. Putting this in C would be a maintenance nightmare.I could see that. Just wanted to float the idea out there for discussion.

--Tony

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

Offline

  • Root
  • » PHP
  • » [PHP-DEV] google SoC - dbobj [RSS Feed]

Board footer

Moderator control

Enjoy the 16th of December
PoweredBy

The Forums are managed by develissimo stuff members, if you find any issues or misplaced content please help us to fix it. Thank you! Tell us via Contact Options
Leave a Message
Welcome to Develissimo Live Support