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
