I was just looking through those classes again. I think ORMRow is generally OK, since it's mostly a simple CRUD wrapper to deal with some of the busy-work of making data access objects. I don't really get the "summary" (updateSummaries/inSummaryMode) stuff though. I guess the callers/subclasses do most of the summary work there or something.
I'm not really fond of ORMTable/ORMResult. A lot of functions are just wrappers around DB calls that don't really abstract much. Also, singleton() has one table instance per table, making foreign wiki access trickier than with the regular LBFactory/DatabaseBase classes. This kind of stuff makes me hesitant to use the classes (since ORMRow depends on the table class). I guess what I'd really like out of those table classes is the support for base API and Pager classes and the minimum needed for ORMRow (fields/types), with foreign wiki support. I like the idea of getAPIParams() and an API base class for making quick API classes. The idea of some base classes for CRUD and API/Pager table listings is fine. It can obviously avoid inconsistency among the DAOs. If these classes are called ORM*, I guess that's OK too, as longs as they don't scope creep into a complex system that coupled to everything and hard to change. -- View this message in context: http://wikimedia.7.n6.nabble.com/Using-ORM-patterns-in-core-tp4984036p4984074.html Sent from the Wikipedia Developers mailing list archive at Nabble.com. _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
