headers
Manuel Lemos | 8 Jun 06:57
Picon
Favicon

Re: [phpdba] native ORM extension for php

Hello,

on 05/27/2007 08:27 PM Hans Lellelid said the following:
>> From what I know, Metastorage is different in many aspects. To install
>> the compiler, you just unpack the archives available for download. It
>> has no external package dependencies and it can run out of box without
>> further configuration.
>>
>> Anyway, Metastorage is just a code generator. The generated code is
>> self-contained, so it does not need any runtime libraries used by the
>> generator.
>>
>> The only runtime library that Metastorage generated code needs is the
>> database abstraction package, which currently is Metabase. Metabase also
>> only needs to be unpacked wherever you want. The only configuration it
>> needs is the database connection string, which is a just an URL that
>> defines the database name, type, host, user, password, etc...
> 
> Yes, these are all fair descriptions of the difference between
> Metastorage and Propel.  Propel does have an external dependency on
> Phing and there is a runtime component for Propel, because Propel
> provides support for OO SQL builder via Criteria object (which obviously
> must be compiled by some runtime component).

Metastorage provides its own Object Query Language (OQL). This allows
developers to express object query conditions of arbitrary complexity,
and Metastorage generates efficient PHP and SQL at compile time.

There is no need to ship any runtime libraries to parse or build queries
because that already happened at compile time.
(Continue reading)

Permalink | Reply | 3 comments |
headers
Manuel Lemos | 8 Jun 07:07
Picon
Favicon

Re: [phpdba] native ORM extension for php

Hello,

on 05/29/2007 02:37 PM Lukas Kahwe Smith said the following:
> Manuel Lemos wrote:
> 
>> By the time that the you tell Metastorage to recompile the your changed
>> object model and use the schema manager class generated by Metastorage,
>> everything, ORM classes code and database schema will be consistent. It
>> will not "crash" as you say.
>>
>> You still need to update your application that uses the model classes.
>> But you also need to update your application when you alter your
>> database schema manually, in order to use added/removed/changed
>> classes/variables/tables/fields.
> 
> Unfortunately I never really got past playing with Metastorage on a
> trivial level (and it was a while ago, I have warmed up to the general

Yes, I remember you used to not be simpathetic with ORM concepts. ;-)

Good ORM tools are always welcome because they can make you more
productive. You spend less time hand coding your model objects, and use
the time more implementing the business logic. It is not just an
academic benefit.

It changes a bit the way you work and how far your applications will go
because with ORM tools it is much easier to implement complex features.

I started with Metastorage in 2002. I regret to not have seen that
opportunity sooner.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Manuel Lemos | 8 Jun 07:18
Picon
Favicon

Re: [phpdba] native ORM extension for php

Hello,

on 05/30/2007 01:56 AM Larry Garfield said the following:
>>> The generated classes are root classes. They do not inherit from any
>>> base class. In the end the generated code is more compact and efficient.
>> While I agree that not re-using code may be faster to execute (but
>> obviously it's going to be slower to parse), I don't think that people
>> are driven to ORM solutions out of pursuite for high-performance PHP
>> code.  Certainly the apps that use any ORM layer would be faster if they
>> did not, but they would also be far less maintainable.  I believe that
>> refactoring re-used code into common base classes or utility classes is
>> good OO practice and makes for a codebase that is more intuitive to
>> users and maintainable.  So I would disagree here with the suggestion
>> taht Smarty would be a better tool if all the shared logic was
>> duplicated in each compiled "template".
>>
>> Hans
> 
> I heartily dislike code generation in general for exactly that reason. :-)  

I know there are plenty of people that oppose to code generation in
general. However, I suppose that is in great part because the lack of
transparency. If you do not know how something is generated, it is easy
to imagine that an automated program will hardly generate well
structured and well formatted code.

But there are many different code generation tools. They do not generate
code with the same quality.

Personally I am very demanding. I wrote a code generation tool and I did
(Continue reading)

Permalink | Reply | 7 comments |
headers
Larry Garfield | 8 Jun 07:46
Favicon

Re: [phpdba] native ORM extension for php

On Friday 08 June 2007, Manuel Lemos wrote:

> > I heartily dislike code generation in general for exactly that reason.
> > :-)
>
> I know there are plenty of people that oppose to code generation in
> general. However, I suppose that is in great part because the lack of
> transparency. If you do not know how something is generated, it is easy
> to imagine that an automated program will hardly generate well
> structured and well formatted code.
>
> But there are many different code generation tools. They do not generate
> code with the same quality.
>
> Personally I am very demanding. I wrote a code generation tool and I did
> not stop until I was satisfied with the quality of the generated code.
> If I am not satisfied, who will be?
>
> I worked hard and invested on generating code that I code look and
> recognize my own style of coding. The code should be just like as if I
> would write it by hand.
>
> Here is an example. If I did not tell you that this was generated by a
> code generator tool, would you have guessed?
>
> http://www.meta-language.net/cvs/metastorage/applications/metanews/componen
>ts/metanews/article.php?rev=HEAD

It's not the coding style that bugs me about generated code.  I've seen 
generated code that visually looks fine (including that <g>).  It's the
(Continue reading)

Permalink | Reply | 4 comments |
headers
Lukas Kahwe Smith | 8 Jun 13:48

Re: [phpdba] native ORM extension for php

Guilherme Blanco wrote:

> I'm not here to say your approach is the best or the worst, but if you
> check my Class Diagram, you can see that it can be easily achieved
> (it's just a lookup in the UDAMap (Uni-Directional Association Map).
> To check if the database supports it, just walk through the mapping
> instances and you'll get the DB vendor.
> After that, the idea will then stay on how to create the trigger
> automatically. The idea of the class schema (pay attention, it's not a
> DB schema) can deal with it and automatically generate the SQL code,
> just like ie. MetaStorage does.

Well there are different targets that require different tools. If you 
are writing a shrinked wrapped portable application, you probably prefer 
some runtime analysis based on the connection (or at least in a config 
file) to determine what code path to take instead of shipping a "fat 
binary" that contains a full generation of code for all possible 
permutations of available features.

However if you only want a standard development tool chain (that may 
allow easy migration to a different RDBMS or configuration) you will 
probably be quite happy with having code that is generated against a 
single version of a given RDBMS.

> I imagine something more complex. I mentioned before about an
> administration tool. I'm going too much over the entire thing, but I
> like to think big.
> With this idea, the DBA just need to update the column in an interface
> like phpMyAdmin. Too much imagination, but a simple change like that
> could rewrite the XML and the approach I described earlier will
(Continue reading)

Permalink | Reply | 0 comments |
headers
Lukas Kahwe Smith | 8 Jun 13:55

Re: [phpdba] native ORM extension for php

Manuel Lemos wrote:

> Metastorage provides its own Object Query Language (OQL). This allows
> developers to express object query conditions of arbitrary complexity,
> and Metastorage generates efficient PHP and SQL at compile time.

Yes, a query language is quite appealing. It means you can easily do 
"one shot" queries without having to hard code each join strategy into 
classes.

> Furthermore, there is another advantage to generating code for queries
> at compile time using an OQL. Metastorage OQL engine is smart enough to
> tell you about syntatic errors at compile time. It knows about syntax
> and types. I do not have to try the code to figure when I made a
> mistake. Metastorage pinpoints me the errors at compile time.
> Metastorage generated code does not have SQL errors that I will only
> figure later.

This is actually a big point. Solutions like LINQ provide similar 
benefits that in PHP you would only get if you use query by API. However 
due to the compilation step in Metastorage you also get syntax checking 
for query by language. Nice.

> Maybe that is what Guilherme is trying to tell you. He does not want to
> get buried in complex configurations. That is so so Java painful. That
> is why Ruby on Rails gained notoriety among Java developers.

So Metastorage just internalized the build toolchain? I guess propel 
could do just the same with phing, but for obvious reasons they prefer 
keeping this an independent tool. I also do not see the challenge in
(Continue reading)

Permalink | Reply | 2 comments |
headers
Lukas Kahwe Smith | 8 Jun 13:59

Re: [phpdba] native ORM extension for php

Manuel Lemos wrote:

> I worked hard and invested on generating code that I code look and
> recognize my own style of coding. The code should be just like as if I
> would write it by hand.

Speaking of coding style, I think this is one of the major concerns 
people have with code generators. it usually does not fit their coding 
style. I guess Metastorage has templates, modifying those would allow 
you to generate code in any coding style, right?

regards,
Lukas
Permalink | Reply | 1 comment |
headers
Lukas Kahwe Smith | 8 Jun 14:01

Re: [phpdba] native ORM extension for php

Larry Garfield wrote:

> It's not the coding style that bugs me about generated code.  I've seen 
> generated code that visually looks fine (including that <g>).  It's the 
> concept of generated code in the first place.  To me, if you have a 
> boilerplate class that differs from another boilerplate class only in the 
> values filled in for certain variables, (or the variable names are different 
> but the structure the same, or whatever), then it means you're not using 
> inheritance properly.  (Ibid for the equivalent for functions.)  

Well inheritance is a means not an end. So essentially Metastorage does 
inheritance at compile time for the most part. This is very friendly to 
PHP that in my experience seems to get bogged down with all too deep 
inheritance structures (though I have not seen this micro benchmarked).

regards,
Lukas
Permalink | Reply | 0 comments |
headers
Hans Lellelid | 8 Jun 16:37

Re: [phpdba] native ORM extension for php

Hi Larry,

Larry Garfield wrote:
> On Friday 08 June 2007, Manuel Lemos wrote:
> 
>>> I heartily dislike code generation in general for exactly that reason.
>>> :-)
>> I know there are plenty of people that oppose to code generation in
>> general. However, I suppose that is in great part because the lack of
>> transparency. If you do not know how something is generated, it is easy
>> to imagine that an automated program will hardly generate well
>> structured and well formatted code.
>>
>> But there are many different code generation tools. They do not generate
>> code with the same quality.
>>
>> Personally I am very demanding. I wrote a code generation tool and I did
>> not stop until I was satisfied with the quality of the generated code.
>> If I am not satisfied, who will be?
>>
>> I worked hard and invested on generating code that I code look and
>> recognize my own style of coding. The code should be just like as if I
>> would write it by hand.
>>
>> Here is an example. If I did not tell you that this was generated by a
>> code generator tool, would you have guessed?
>>
>> http://www.meta-language.net/cvs/metastorage/applications/metanews/componen
>> ts/metanews/article.php?rev=HEAD
>
(Continue reading)

Permalink | Reply | 1 comment |
headers
Lukas Kahwe Smith | 8 Jun 18:14

Re: [phpdba] native ORM extension for php

Hans Lellelid wrote:

> At a more philisophical level, I think there is an inherent duplication
> in any ORM solution.  You are mapping between objects and relational
> systems: the relevant information in the relational systems has to
> somehow be expressed in the OO architecture.  So, it's more a matter of
> choosing where/how that duplication happens, not whether it happens.
> Hopefully that made some sense :)

Yeah, there is no way around it really. You need to define constraints 
inside the database and in your model, in your UI etc. Ideally however 
all of this would be generated from a single source.

regards,
Lukas
Permalink | Reply | 0 comments |

Gmane