Sean, On Dec 31, 2008, at 12:34 PM, Sean Allen wrote:
i'm in an interesting position here... i have some old crufty perl code that was going to be scrapped and rewritten not in perl, said rewrite might have to be delayed but i still need to make the perl code usable. two things needed for that... decent object model ( hello moose ), fairly brainless way to store said objects... if a .09 is contemplated, how long between contemplation and initial work starting on it? I think if I use DBIC given the timing of mid february to rip the guts out and replace, that .081 would be the path I need to follow if I use DBIC.
If you need a brainless way to store objects and do not have an a requirement of that storage being a relational DB with a sane schema then you should look at KiokuDB. We have used the BerkeleyDB backend very successfully for $work and Yuval recently created a DBI backend as well (NOTE: the DBI backend is *not* an ORM but instead using RDBMS as the backend store for the collapsed KiokuDB objects).
If you have a requirement of a relational DB with a sane schema I would suggest using regular old DBIC. Moose & DBIC play pretty well together so you can use Moose to augment the regular DBIC classes (several people have been doing this for a couple years now, so I know it works). This will help future-proof your app as well because once DBIC gets ported to Moose your code will Just Work (mst & the dbic crew are rigorous about backwards compat) and you will likely only need to do some slight refactoring to update it to use the best of the Mooseified-DBIC.
Also, it is very important to note that Moose was built from the very start to play well with non-Moose code and to allow for incremental and partial Mooseification of older code-bases (I have about 3 medium- large production apps that are between 50% and 80% Moosified). In other words, you can sip the Kool-aid slowly at your own pace instead of having to drink it all down in one big gulp.
- Stevan
