John, Thanks for the detailed reply.
On 4/25/06, John Siracusa <[EMAIL PROTECTED]> wrote: > On 4/24/06 5:52 PM, Clayton Scott wrote: > > My schema has a table "address". When using the default ConventionManager > > and autogenerating classes the coresponding class will have it's last > > 's' dropped > > to become "Addres". > > > > I expected that using RDBO::ConventionManager::Null would prevent that > > from occuring. > > The convention manager is asked to "fill in the blank" when there is no > explicit information given for a piece of metadata. When you use the > Loader, auto_initialize(), or even if you set up a class manually and just > leave certain pieces of information out, the convention manager is called > upon to provide the missing information. Here's an example of a convention > manager method: table_to_class(). Given a table name, it's supposed to > return a name for the RDBO-derived class to front that table. OK. I interpreted/assumed that if the default RDBO::ConventionManager performed the transformations ont eh tablenames the RDBO::ConventionManager::Null that does nothing would not attempt to perform those transformations. > Obviously, using the Null convention manager will not solve your problem. > When RDBO calls table_to_class('address') to generate the appropriate class > name for that table, it's going to get back undef rather than "addresses" or > "address" or anything else useful. Understood. As I mentioned, I was "hoping" returning undef would prevent the transformations. I'll have to peruse the Conventions docs a few more times to write my own ConventionManager > So, why would anyone ever want to use the Null convention manager? It's > useful for people who want to make sure that they explicitly provide all > metadata. Using the Null convention manager ensures that no information is > automatically created for you. If you leave something essential out, you'll > get an error instead of a "best guess" from the CM. Some people like that > assurance. Something for me to file away for later, then :) > As for your particular problem, you've discovered that the default RDBO CM > expects table names to be plural, as documented here: > > [ snipped ] Yes, I had read that in the docs and ConventionManager::Null was my leaping point to see what would happen; and test my interpretation of the docs as I outlined above. > The solution is to create your own convention manager subclass. > [ snip ] > Here's a (very primitive) example: > > package My::ConventionManager; > use base 'Rose::DB::Object::ConventionManager'; > > sub plural_to_singular > { > my($self, $word) = @_; > return 'address' if($word eq 'address'); # already singular! > return $self->SUPER::plural_to_singular($word); > } > [ rest of example snipped ] What kind of problems can I expect to run into if I reimplement the plural_to_singular and the other related methods to do the equivalent of: sub plural_to_singular { my($self, $word) = @_; return $word; } I ask because I'm trying to determine whether I should implement my conventions in code or just adopt yours :) -- Clayton Scott [EMAIL PROTECTED] ------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid0709&bid&3057&dat1642 _______________________________________________ Rose-db-object mailing list Rose-db-object@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rose-db-object