CODEWITHSUNDEEP
databasezend-frameworkormsymfony1propel
rhaag71
rhaag71

Reputation: 519

Zend with existing Propel ORM

I'm working on converting a rather large (but somewhat simple) app from Symfony to Zend, large because of the DB. This is also my first Zend project, but it seems to be going well so far. The app is simple, the DB is fairly complex (I foresee many hours of datamapping ahead if done manually).

I have all the original source code that was done using the Symfony FW. The original uses propel and works (and has over 200 models mapping the DB, 272 at quick glance).

My DB tables have dependent row after row, I am also reusing the original DB structure...straight import of tables/schema, so I imagine that the original propel would still work fine in that respect.

My question(s) is/are, would it be time well spent trying to reuse the propel section of the old app w/ my new Zend based version of the app? Should this be straight forward venture?

If this could work, it may remove many sleepless nights from my life :)

Upvotes: 3

Views: 507

Answers (3)

rhaag71
rhaag71

Reputation: 519

For the benefit of others who may look in here, I am going to answer my own question...

What I ended up doing is installing the latest version of Propel (1.5). Jan Fabry(above) mentioned that there may be residual elements to the previously generated models (from the SF project), and that was a concern of mine as well. So I ran a 'reverse' on the database and generated new schema/models too.

I am certainly keeping the original generated models close at hand for reference, as I am reusing the existing database. I also ran a phpDoc build on the previous app, including the generated Propel models and that is serving as a great tool to see what was done before. As a 'side' tip, I also ran phpDoc on my new generated models and I now have a sort of 'reference' doc to my new 'custom db api' that was generated from the Propel build...really cool! There are some schema issues already, like the lack of support for ENUM types...but coming in v1.6 of Propel. The original models serve as a working example of how Propel was used with the existing database. I foresee editing 'by hand' a few entries in the new schema when the issues arrise.

The v1.5 of Propel has a new 'query' API (pointed out by Frosty Z) that is replacing (or enhancing) the 'criteria' and 'peer' in my new app. The original code still serves as a good model (not MVC model) as to how the database was integrated into the app's logic before, but I am finding that the new version of Propels 'query' API is going to be a big help.

I read that Propel does not support 'joins' somewhere, but I see that this version does, and there are many other new & useful features in Propel. Quite notably, the way that the new API handles relationships. It's all in the docs at Propel, and I'm eager to use it. The database is kinda large and complex for a 'manual' interface, so the 'reverse' feature of Propel was very handy as well.

Queries like this one:

                    $Users = UsersQuery::create()
                  ->filterByLastName($LastName)
                  ->find(); // $Users is a PropelCollection object
                 return $Users;

is quite "nice" as Frosty Z said, and saves a lot of coding compared to using the Zend_Db, or straight PHP/MySQL, and seems more simple than the former 'criteria', 'peer', way. That snippet came from the Propel Docs, and solves the problem that made me look elsewhere for a solution, a conditional find seemed that it was going to grow in code size comparatively. And I can already see how easy it will be to filter results in accordance with ACL's.

My answer is an explanation of why I'm not re-using the original models; lack of new methods & fear of residual code that may cause bugs or headaches, and why I stuck with Propel (besides the fact that it seems really nice); I have an existing example of a working ORM. Really, I can say that both answers above are what I went with. Thanks guys!

Upvotes: 0

Jan Fabry
Jan Fabry

Reputation: 7351

The model classes can contain references to Symfony classes, like sfMixer. They are added by extra Propel behaviors in the Symfony distribution. Because sfMixer will probably not exist in your new Zend project, this can lead to errors.

However, it should be possible to re-generate your models with a clean Propel installation (in Zend, or in Symfony with the extra behaviors disabled), and then copy your own user-editable class files over the empty generated ones.

If you use the same version of Propel in your Zend project as you did in your Symfony project, this should work out of the box (unless you edited the Base classes, but I assume you did not do that). If you are using a newer version of Propel in Zend to generate the models, there might be compatibility issues if you access protected members that since have changed.

Upvotes: 3

Maxime Pacary
Maxime Pacary

Reputation: 23001

I think that you can reuse the Propel sections of the old app, since Propel 1.5 (current stable) and the next 1.6 are backward compatible down to Propel 1.3 (used by Symfony 1.0 if I remember well) and its original "Criteria" syntax.

You will then benefit for the Propel 1.5 improvements (among them, the nice "Query" syntax), without losing the existing code.

See:

Upvotes: 4

Related Questions