[Dbix-class] DBIx::Class::Schema::Loader with multiple schemas

[Ben Tilly]

It should only need overwrite_modifications set to true once.

The filter should happen BEFORE the checksum is calculated.  So as
long as you use the same filter, it should just work.  Of course if
you go from not using a filter to using one, the checksums so not
match and you have to overwrite_modifications.  But every time you
change the filter, you will need to overwrite_modifications (once).

If it does not work this way, then you should file a bug report.

On Wed, Dec 19, 2012 at 2:31 PM, Nick Anderson <nick at webcraftcs.com> wrote:
>
> Thanks Ben,
>
> Looks good to me! Seems to need overwrite_modifications set to true which
> isn't ideal but will do for now.
>
>
> Nick
>
>
> On 19/12/12 20:50, Ben Tilly wrote:
>>
>> Well, if you want the bad sledgehammer approach, look for
>> filter_generated_code in DBIx::Class::Schema::Loader::Base and use it
>> to get rid of the prefix that you don't want.
>>
>> On Wed, Dec 19, 2012 at 12:06 PM, Nick Anderson<nick at webcraftcs.com>
>> wrote:
>>>
>>> Hi,
>>>
>>> I am trying to use DBIx::Class::Schema::Loader to create a schema for two
>>> inter-related databases but am having trouble where it insists on
>>> prefixing
>>> with the database name:
>>>
>>> __PACKAGE__->table(db_prefix.table_name);
>>>
>>>
>>> With one database, it doesn't include the prefix.
>>>
>>> With two it includes it even where there are no conflicting table names.
>>>
>>>
>>> I need to run many individual copies of database A (client virtual host
>>> databases), which are each linked to a master/lookup database B
>>>
>>> For the schema I would like it to produce:
>>>
>>> __PACKAGE__->table(table_name); -  for database A tables (no prefix)
>>>
>>> __PACKAGE__->table(B.table_name);  - for database B tables (prefix)
>>>
>>>
>>> The reason I don't want the database A prefix is because I can then
>>> operate
>>> many copies of database A (e.g. same structure, different users) and can
>>> ignore the database name.
>>>
>>> The only way I can find to get around this at the moment is to manually
>>> change the "__PACKAGE__->table" lines, but clearly this is not an
>>> acceptable
>>> long term solution.
>>>
>>> moniker_map/moniker_parts seem to refer to something else and don't alter
>>> the "__PACKAGE__->table(dbic_name)"
>>>
>>> Does anyone have any ideas please?
>>>
>>> Thank you
>>>
>>> Nick Anderson
>>>
>>> _______________________________________________
>>> List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class
>>> IRC: irc.perl.org#dbix-class
>>> SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/
>>> Searchable Archive:
>>> http://www.grokbase.com/group/dbix-class@lists.scsys.co.uk
>>
>> _______________________________________________
>> List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class
>> IRC: irc.perl.org#dbix-class
>> SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/
>> Searchable Archive:
>> http://www.grokbase.com/group/dbix-class@lists.scsys.co.uk
>
>
>
> _______________________________________________
> List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class
> IRC: irc.perl.org#dbix-class
> SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/
> Searchable Archive:
> http://www.grokbase.com/group/dbix-class@lists.scsys.co.uk