Well, from
http://www.doctrine-project.org/documentation/manual/1_1/en/introduction#minimum-requirements
you would need PHP 5.2.3 or later and the PDO extension, and from
http://www.doctrine-project.org/documentation/cookbook/1_1/en/my-first-project
you need command line access to the server. According to this
http://helpdesk.hostmonster.com/index.php/kb/article/000179
Host Monster does give you SSH access on request. But the only way I
see to find out what PHP version is available is to run phpinfo() on the
server, and you need to log in to the account to do that.
-- Walt
Justin Giboney wrote:
To follow up on this question, can these ORMs be installed if you don't
have access to the full server. For example I have a client that setup
his host as Host Monster and I don't know if I'll be able to install an
ORM on it. Doctrine seems to need to be installed as an application.
Are there any that don't require full access to the server?
Thanks,
Justin Giboney
On Jul 21, 2009, at 7:10 PM, Justin Hileman wrote:
Kirk Ouimet wrote:
Had a couple questions to post this morning. This one is very
open-ended.
I've been looking at PHP ORM's like:
http://www.doctrine-project.org/
They're absolutely worth your time to learn. They're super rad, and
usually a bit fickle. And, as others have pointed out, they're not the
best answer for everything. But they're definitely the best answer for
a lot of things.
My team is using Doctrine on a PHP platform with a pretty complicated
model, and the ORM makes traversing that model *far* easier.
Unfortunately, Doctrine isn't magic. One of my guys threw together a
bulk import script that could peg a dual-quad Xeon until PHP timed out
and still not finish... We converted the inner loop into a direct SQL
insert and the import script could finish in a couple of minutes. So
be sure to watch for places you can optimize.
That said, we still use the ORM for almost everything. We have over a
hundred model classes in in the project (~150 DB tables) and we have
about 18 "normal" SQL queries in the app.
I was curious so I just grepped the source code. Looks like we fall
back to SQL in only a couple of cases:
* Bulk import, as mentioned above
* Bulk export/reporting -- although a lot of reporting is done through
Doctrine, because it builds all the heinous joins for us :)
* Pagination -- The version of Doctrine we're using has a bug that
misreports pagination data... It pages the queries just fine, but lies
about how many total rows exist, so we ignore what it tells us and ask
directly via SQL.
* And one other place where I'm pretty sure it should have been done
in Doctrine. I'll chat with the developer that wrote that code, see if
he has a good reason for it :)
--
justin
http://justinhileman.com
_______________________________________________
UPHPU mailing list
[email protected]
http://uphpu.org/mailman/listinfo/uphpu
IRC: #uphpu on irc.freenode.net
_______________________________________________
UPHPU mailing list
[email protected]
http://uphpu.org/mailman/listinfo/uphpu
IRC: #uphpu on irc.freenode.net
_______________________________________________
UPHPU mailing list
[email protected]
http://uphpu.org/mailman/listinfo/uphpu
IRC: #uphpu on irc.freenode.net
