| Author |
Message |
|
Seikilos
|
Post subject: Re: Use ORM as database abstraction layer  Posted: Sun Apr 25, 2010 7:22 am |
|
Joined: Sat Feb 27, 2010 9:42 am
Posts: 30
|
|
No it doesnt.
You require cmd line tools while developing and no one does really dev on a staging server, so you develop locally. Locally you use the cmd to transform schemas into sql syntax and so on, the results are classes (many of them in the beginners view) which you simply upload to the webspace.
So while you develop you need the cmd, after developing is done you dont.
The schema should anyway never be modified online since this would mean you run out of sync with your local dev tree which should typically be under source control
|
|
  |
|
 |
|
maskas
|
Post subject: Re: Use ORM as database abstraction layer Posted: Sun Apr 25, 2010 8:05 am |
|
 |
| Project Developer |
Joined: Tue Apr 28, 2009 9:43 am
Posts: 1720
|
|
Thank you for detailed information. I still wait others to join the discussion.
|
|
| |
|
|
|
maskas
|
Post subject: Re: Use ORM as database abstraction layer Posted: Sun May 02, 2010 1:14 pm |
|
|
| Project Developer |
Joined: Tue Apr 28, 2009 9:43 am
Posts: 1720
|
Wen I talk to web developers in personal, they say, that ORM is to difficult for many of them. So we think about PDO. Main pros: - easy to learn
- fast
- database independent
- automatic escaping of variables
Cons: - no automatic way to retrieve object from database or save to database
|
|
| |
|
|
|
Seikilos
|
Post subject: Re: Use ORM as database abstraction layer Posted: Sun May 02, 2010 2:03 pm |
|
Joined: Sat Feb 27, 2010 9:42 am
Posts: 30
|
Can you describe the cons more clearly? What is automatic? I retrieve something like Code: $user = UserPeer::retrieveByPk(1); Ok, primary key. Other way Code: $user = UserPeer::retrieveByMyCustomMethod("nickname"); Saving: Code: $user = new User();
$user->setName("foobar");
$user->save(); here the ORM takes the responsibility to create a transaction, optimize query, write and commit the transaction. All these methods except the custom one is automatically generated from the schema definition. It does escape the input, store and retrieve.
|
|
| |
|
|
|
maskas
|
Post subject: Re: Use ORM as database abstraction layer Posted: Sun May 02, 2010 2:23 pm |
|
|
| Project Developer |
Joined: Tue Apr 28, 2009 9:43 am
Posts: 1720
|
|
I wrote about pros and cons of PDO. And in PDO you can't simply say: $user->save(); You need to write an SQL. It is what I mean by automatic. And it is disadvantage of PDO.
|
|
| |
|
|
|
Seikilos
|
Post subject: Re: Use ORM as database abstraction layer Posted: Sun May 02, 2010 5:19 pm |
|
Joined: Sat Feb 27, 2010 9:42 am
Posts: 30
|
Ah sure, my fault, was somehow on the ORM train 
|
|
| |
|
|
|
Xllerator
|
Post subject: Re: Use ORM as database abstraction layer Posted: Wed May 05, 2010 1:43 am |
|
Joined: Wed May 05, 2010 1:16 am
Posts: 8
|
|
IMHO, although Propel looks nice, it's geared towards the big stuff while ImpressPages isn't. I mean IP is supposed to create fast, fairly simple and easy to manage websites, isn't it? Its speed comes from its lightweight, not from some supposedly superoptimized query (at the expense of a steep learning curve for devs, anyway). Then what's doing Propel in this equation?
I second Sokolowski, putting effort in adding more modules is better.
|
|
| |
|
|
|
maskas
|
Post subject: Re: Use ORM as database abstraction layer Posted: Thu May 06, 2010 6:10 am |
|
|
| Project Developer |
Joined: Tue Apr 28, 2009 9:43 am
Posts: 1720
|
|
valuable opinion. I still wait more people to join the discussion.
|
|
| |
|
|
|
Seikilos
|
Post subject: Re: Use ORM as database abstraction layer Posted: Thu Oct 25, 2012 2:57 pm |
|
Joined: Sat Feb 27, 2010 9:42 am
Posts: 30
|
Every decent provider (usually one that does not use safe_mode on  ) Can host Propel and Doctrine. I've deployed both on shared hosts without a problem since they do not install but simply exist. I've used both ORMs while working with the Symfony(1 and 2) Framework
|
|
| |
|
|
|
