On Fri, 21 Dec 2007 16:11:08 -0800 Darren Duncan <[EMAIL PROTECTED]> wrote:
DD> At 6:20 PM -0500 12/21/07, John Siracusa wrote: >> On 12/21/07 3:43 PM, Ted Zlatanov wrote: >>> I've set up all the right things in a Rose::DB class to support this. >>> Now I find myself with the need for four class hierarchies to handle >>> slightly different things in those four environments. Instead, I'm >>> wondering if I can have: >>> >>> DB/auto/prod/a/Cats.pm >>> DB/auto/prod/b/Cats.pm >>> DB/auto/dev/a/Cats.pm >>> DB/auto/dev/b/Cats.pm >>> DB/Cats.pm >>> DB/BaseObject.pm >> >> Ick. I think the root problem is that you have four sets of tables that are >> "99%" identical :) You can avoid code duplication by subclassing, but it's >> still ugly. DD> I agree. What you *should* do is generalize your database schema a DD> bit more so that it is 100% identical for all databases, and simply DD> have appropriately different data in them, and/or an app config file DD> setting that you set differently for different scenarios, such as to DD> use or ignore the extra timestamp. Both of you are telling me things I already know. I don't have control over the discrepancies between production and development; it would be nice if they were always in sync but they are not. The question is how to cope with the inconsistency, and RDBO doesn't have any mechanism AFAIK other than the domain/type mechanism in Rose::DB. Ted ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Rose-db-object mailing list Rose-db-object@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rose-db-object
