Hello Banko,
I remember that you proposed an ORM written in C/C++ last year around
the same time. Back then I was quite opposed to the idea, saying that
something like this best belongs in userland, and that at most certain
bottleneck features should be moved to C (following the example of
2007. 03. 27, kedd keltezéssel 16.55-kor Jeff Moore ezt írta:
>
> Hi,
>
> Sorry, I'm coming to this discussion a bit late and perhaps I don't
> understand the all issues, but I think the scope of creating an ORM
> for PHP is probably too large. Let me suggest a smaller project that
> could
Hi,
Sorry, I'm coming to this discussion a bit late and perhaps I don't
understand the all issues, but I think the scope of creating an ORM
for PHP is probably too large. Let me suggest a smaller project that
could lead to better ORM.
PHP has several methods of serializing and unseria
> I do think it would be easier to come up with a standard for the project, if
> perhaps Banko didn't spend a whole year and a half on it. I do hope that the
> mailing list sorts out which features should be in the PHP extension to allow
> for interoperability between the ORM PHP libraries. It w
Developing the extension like SPL would allow for very quick development and
maintainability for the extension. It is extremely easy to have interfaces,
exceptions, and in some cases abstract classes written in C and easily updated
when changes, if any, are made.
I was able to translate a grea
> you can do the same with XP too. As in PHP so in C you will have to
> establish a common ground on which the further development will stand
> on. Then part by part implement in PHP and port to C. Having tests will
> help a lot.
Maybe you are right, but I don't like the idea of doing everything
t
Hi,
Bankó Ádám wrote:
>> Then make a mix of PHP and C code. C call call PHP userland, so it
>> shouldn't be a problem.
>
> I don't want to write a full ORM, only a common base, that others can
> extend .. for example with INI/XML file configuration, schema auto
> discovery etc.
>
>> And as I see
Hi,
Lukas Kahwe Smith wrote:
> Robin Ericsson wrote:
>> On 3/21/07, Bankó Ádám <[EMAIL PROTECTED]> wrote:
>>> The project is existing, I'm doing it for about a year and a half, and
>>> SoC is way I can spend more time on it in the summer.
>>
>> If there is someone willing to something, and someone
Andrey Hristov wrote:
Hi,
Lukas Kahwe Smith wrote:
Robin Ericsson wrote:
On 3/21/07, Bankó Ádám <[EMAIL PROTECTED]> wrote:
The project is existing, I'm doing it for about a year and a half, and
SoC is way I can spend more time on it in the summer.
If there is someone willing to something, an
> Its a question of maintainability. Stuff like reverse engineering
> schema's from a database is simply not sensible to be done by C code. It
> requires a low barrier to entry, the ability to quickly fix things if
> you encounter a newer or very old obscure RDBMS version etc.
Doing database sc
On 3/21/07, Bankó Ádám <[EMAIL PROTECTED]> wrote:
The project is existing, I'm doing it for about a year and a half, and
SoC is way I can spend more time on it in the summer.
If there is someone willing to something, and someone else is paying
for it, let him do it. Why should it bother whether
> I believe that PHP should have a bundled feature that can even support
> OO approach for OO enthusiasts (like me) and also Structural. If not
> bundled, support the project like Smarty, something like
> http://orm.php.net
> ...
> I have to say that your idea is good enough to even be out of Googl
Robin Ericsson wrote:
On 3/21/07, Bankó Ádám <[EMAIL PROTECTED]> wrote:
The project is existing, I'm doing it for about a year and a half, and
SoC is way I can spend more time on it in the summer.
If there is someone willing to something, and someone else is paying
for it, let him do it. Why s
Guilherme Blanco wrote:
As I mentioned before, the best ORM tool I've notice is Doctrine, but
it has some issues that I can list if necessary. The point is not to
BTW: the lead author of Doctrine aready submitted an SoC project idea
for php.net on googles website.
regards,
Lukas
--
PHP Int
I agree that the optimal solution would be a base ORM solution that all others
can build off of and use. Just like PDO, it doesn't have to be an end all
solution. Just implement the major features that all ORM projects have.
The mailing list is great to pick at the brains that have been buildin
Hi,
I'd like to help you in this working draft, but I don't have too much
experience with C/C++ to holp with code, but... I can try something.
Also, I suggested you that white paper since it supports almost
everything expected from a robust ORM tool. I still believe that your
performance gain w
2007. 03. 19, hétfő keltezéssel 16.51-kor Richard Lynch ezt írta:
> I don't think you'd want the RAM/performance hit of that, even in C...
> [shrug]
>
> OTOH, I don't think I'd even want to use an ORM, so feel free to
> ignore me completely. :-)
>
Hi!
I think a code is more manageable if it's m
On Mon, March 19, 2007 1:59 pm, Bankó Ádám wrote:
> 2. In C I can implement all the structure I want (as long it's sane)
> without much worrying about what performance cost it will have. I
> wouldn't do the same in PHP. I'm talking about separate classes for
> every database column type and abstrac
Hello!
This paper seems to be interesting, but I don't have the time to read it
now. If only there were such nice documentations when I started this!
On the performace point, I can't say anything well-grounded since I have
no benchmark results. I'll do some when I have a little more time, then
we
Hi,
This is an interesting project!
I am currently implementing an ORM tool based on this white paper from
Mr. Scott W. Ambler (from IBM):
http://www.ambysoft.com/essays/persistenceLayer.html
I think that a compiled C ORM tool doesn't have too much advantage
over a PHP code based. The performanc
First, here's what I've done so far in the subject:
http://dbobj.sourceforge.net/bzr/dbobj/
And here's a quite dreary wiki feel free to update it...
http://dbobj.sourceforge.net/wiki/HomePage
However, there are some notes on these:
1, I didn't spend much time on documentation writing, because bot
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
Just curious - which access do you need that PHP API doesn't give?
And one more poi
Tony Bibbs wrote:
Sorry, I wasn't clear on this. Creole is the DB abstraction layer on top
of the "old extensions". The older versions of Propel were implemented
that way. The new beta version uses PDO dicrectly (i.e. minus Creole)
and that showed significant speed improvements over prior ve
Lukas Kahwe Smith wrote:
FYI: You are mistaken if you think that moving from the old extensions
to PDO provides a speed improvement (there is rather decrease unless you
are using fetchAll()).
Sorry, I wasn't clear on this. Creole is the DB abstraction layer on top
of the "old extensions".
Tony Bibbs wrote:
I agree. I'm a user of Propel (http://propel.phpdb.org) which is in the
user space as you suggest and I think it works fine. The current beta
version of Propel uses PDO so execution speed isn't really a huge
FYI: You are mistaken if you think that moving from the old exte
Lukas Kahwe Smith wrote:
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
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
> 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
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 time
I would hope that the solution for "low level object API" would b
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
brilli
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
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 intereste
32 matches
Mail list logo
