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
