Re: Search for ORM with Multi-Table-Object Support

in reply to Search for ORM with Multi-Table-Object Support

I'm not the biggest fan of ORMs (they look nice and dandy at first, and then they hurt), so I don't know the answer to your question.

But,

I want to be able to change database-layout (up to a certain extent) without having to change tons of lines of sql code widely spread among hundreds of modules and scripts.

Do note that you don't need an ORM to be able to archive that. You can easily write a layer (and it's up to you to determine how many files this layer has) that provides access to the database -- that is, if you change the layout of your database, all you need to change is this layer. In fact, this layer can be written in the database itself (stored procedures) or in a different language. There's no need to map each row into an object. That's just one way of doing it.

Comment on Re: Search for ORM with Multi-Table-Object Support

Replies are listed 'Best First'.
Re^2: Search for ORM with Multi-Table-Object Support by Xel (Novice) on May 02, 2012 at 21:21 UTC
Thanks for the annotation. You are surely right - and I know about the caveats of ORMs. Of course one does not need to do it the OO way - but we really need a place to store all the stuff which has to be done whenever records are processed in any way. This can be done in an static module or in an object as well. I think it is attractive to do both (abstraction and collecting all the code) in one step. In regard to stored procedures I do not dare to use them, because we hat massive trouble in using triggers in our replication due to mysql-bugs (which were really tricky to hunt down) and I have no interest in bugtracing mysql's stored procedures with replication...	[reply]

Replies are listed 'Best First'.

Re^2: Search for ORM with Multi-Table-Object Support
by Xel (Novice) on May 02, 2012 at 21:21 UTC

Thanks for the annotation. You are surely right - and I know about the caveats of ORMs.

Of course one does not need to do it the OO way - but we really need a place to store all the stuff which has to be done whenever records are processed in any way. This can be done in an static module or in an object as well.

I think it is attractive to do both (abstraction and collecting all the code) in one step.

In regard to stored procedures I do not dare to use them, because we hat massive trouble in using triggers in our replication due to mysql-bugs (which were really tricky to hunt down) and I have no interest in bugtracing mysql's stored procedures with replication...

[reply]

In Section Seekers of Perl Wisdom