On Mon, Oct 27, 2008 at 6:12 PM, Noah Kantrowitz <[EMAIL PROTECTED]>wrote:
> > This shares all the same downsides as the existing SA branch. Using an ORM > provides very little tangible benefit Database independence seems to be fairly tangible to some on the list. That is one thing that comes nearly free with ORM. > for non-trivial overhead [and] general obfuscation. agreed. ORM should not be thrown at every problem. > The idea of using SA was always just to use it as a cross-DB > API, not as an ORM as far as I remember. Really the only benefit is some of > the common operations in the model classes are autogenerated, but those are > a) only written once per model anyway, b) easy to cut-n-paste from another > model, and c) don't change often enough to warrant this kind of > complication. > In this case I think of complication in two ways: the complication of the entire system, versus the complication of the testable parts. If you are able to make parts of your system easier to test with ORM, it can be a net positive in the complication realm. And for a) and b), code generation provides a single template to maintain that code in. Ted --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Trac Development" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en -~----------~----~----~----~------~----~------~--~---
