[Dbix-class] Restore old behavior of DBIx::Class::Loader

[Dagfinn Ilmari Mannsåker]

Александр Поволоцкий <tarkhil at over.ru> writes:

> On 08.07.2020 19:26, Karen Etheridge wrote:
>
>> On Wed, Jul 8, 2020 at 5:23 AM Александр Поволоцкий <tarkhil at over.ru
>> <mailto:tarkhil at over.ru>> wrote:
>>
>>>      Hello
>>>
>>>     I'm developing a project of about 36000 lines of perl code for
>>>     now, and some time ago I've found that dbicdump begins to
>>>     process monikers' names differently.
>>>
>>>     Sample diff of one of generated modules
>>>
>>>       Type: belongs_to
>>>
>>>     -Related object: L<Billing::Schema::Result::ClientState>
>>>     +Related object: L<Billing::Schema::Result::AuxClientState>
>>>
>>
>> "Aux" is not a special prefix in DBICL -- did some of your table names
>> change?
>>
>> You can override how some of the names work with a configuration file
>> -- see all the options documented in
>> DBIx::Class::Schema::Loader;:Base. I suspect you can do what you need
>> with some entries in 'moniker_map'.  Perhaps you had a configuration
>> file before but it was removed after the last regeneration was done?
>
> It's a namespace name. dbicdump used to ignore namespace, now it's using
> it :(

That is controlled by the `moniker_parts` option, which has `schema`
prefixed to it if there are tables with clashing monikers in different
schemas.  To avoid this you need to either provide a `moniker_map` that
makes them not clash, or an `exclude` that filters out all but one of
the clashing tables.

https://metacpan.org/pod/DBIx::Class::Schema::Loader::Base#moniker_parts

- ilmari
-- 
"The surreality of the universe tends towards a maximum" -- Skud's Law
"Never formulate a law or axiom that you're not prepared to live with
 the consequences of."                              -- Skud's Meta-Law