• 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Propel ORM?

#1
[eluser]jgberg[/eluser]
Based on Hibernate and a google developer podcast I found the Propel ORM which looks interesting. On the wiki is a unfinished and therefore useless article about Propel and CI. I'm looking for any opinions on Propel and on using Propel and CI together.

Thanks!
Jeffrey Greenberg

#2
[eluser]Derek Allard[/eluser]
It does look interesting, but at this point, CI remains committed to PHP 4 compatibility, and this appears PHP 5 only.

Note not directed to Jeffrey, but anyone reading this: Please don't use this thread to debate the merits of CI supporting PHP 4 Smile

#3
[eluser]jgberg[/eluser]
Thanks Derek. But that should not end the discussion. Given that CI does work with PHP 5 (which I vastly prefer), I'd still like to get informed opinions on Propel and Propel-with-CI. This is mainly coming from the thought that a nice ORM would be vastly helpful for improving productivity, given RoR as one example of an ORM nicely integrated such that the each evolution of the DB is also change controlled... I want that!

Cheers,
Jeffrey

#4
[eluser]Derek Allard[/eluser]
Absolutely! Sorry Jeffrey, I owe you an apology. I read your post as "CI should use propel as its ORM library" and not as "how do I use propel with CI". Sorry mate, on second reading I got that one wrong. As an attempt to make it right, I offer this Wink

http://codeigniter.com/wiki/Using_Propel_as_Model/

#5
[eluser]jgberg[/eluser]
thanks... ironically, that's the wiki article I was thinking of above... it's not really complete at all... So we need more info.
jeffrey

#6
[eluser]Rick Jolly[/eluser]
Other ORMs:

Doctrine http://www.phpdoctrine.net/trac/
The new kid. It is built on PHP 5 PDO so it should be the fastest ORM. No seperate schema file required. It defines data types and table relationships in methods within the model.

EZPDO http://www.ezpdo.net/
Innovative because it uses comments in the models to determine data types and table relationships. Therefore, like Doctrine (and unlike Propel and DB_DataObject), there is no seperate schema file to maintain. However, it is probably the slowest ORM.

Pear DB_DataObject http://pear.php.net/package/DB_DataObject/
PHP 4 and maybe the easiest to use. It makes the simple things simple and the more difficult things (joins) possible. Not a full-blown ORM. Can be used without a schema file for determining datatypes, but that requires first querying the database for metadata which is slow.

As for integrating any of these into CI. That's fairly straightforward: just set the include path and require() or include() them.

#7
[eluser]jgberg[/eluser]
reading through some propel 1.2 docs, I see that it generates sql files which you then use to alter the database. But unlike RoR it does not seem to support the rollback or forward capability; in RoR you can specify the transformations to the schema/data that are needed to take you forward and even back a rev. Pretty nice really...

#8
[eluser]kucerar[/eluser]
Ug...to each his own, but I hope nobody hands all that XML off to me to maintain...think downstream.

I for one will be experimenting porting the ATK widgets over to CI. Everything there is spec'ed out in PHP code, and it actually binds the table, rows and columns and stuff to your forms. Isn't this the one thing the .NET folks have been able to do for years now? and they never let anyone forget it?

-R

UPDATE on ATK: The key there is the PARTIAL rendering. There's and HTML_PARTIAL flag to pass to the subcontrollers. Hopefully that'll get me just a plain vanilla form but with the bound widgets expressed in the node spec php code. This would let me bypass the whole front end and put CI there instead for the outer control function and the view.

#9
[eluser]kucerar[/eluser]
[quote author="kucerar" date="1187055017"]
I for one will be experimenting porting the ATK widgets over to CI...

UPDATE on ATK: The key there is the PARTIAL rendering. There's and HTML_PARTIAL flag to pass to the subcontrollers. Hopefully that'll get me just a plain vanilla form but with the bound widgets expressed in the node spec php code. This would let me bypass the whole front end and put CI there instead for the outer control function and the view.[/quote]

UPDATE on the UPDATE:

The CI "bolt-on" is going ok I guess.

A missing tpl directory in the smarty tempdir messed up everything. Smarty is some scary code if you ask me. Nearly impenetrable.

Finally got a listing through a CI controller by calling ATK as a lib. Unfortunately all the links are not acceptable by CI.

ATK is too monolithic with the URLs it constructs--it can't be changed to RESTFUL because the assumptions of an ATK frontend is all interweaved everywhere.

And CI is too touchy to process the kinds of URLs that ATK generates.

Therefore I'm now thinking iFrames to grab pieces and form flows of ATK, those go directly to ATK controllers.

CI just handles the outer shell. Both happy. ATK can't really be used as a library as it stands.

-R

#10
[eluser]EpochWolf[/eluser]
I've been looking for how to integrate Propel and CI. Does anyone have any information beyond the half-written wiki entry?

(Kinda off topic: For those that find the XML ugly, I've got a solution for that. Look up DBDesigner 4, create your database in it, then find a converter from DBD's xml to propel XML. There is one out there.)


Digg   Delicious   Reddit   Facebook   Twitter   StumbleUpon  


  Theme © 2014 iAndrew  
Powered By MyBB, © 2002-2021 MyBB Group.