Skip Menu |
 

This queue is for tickets about the DBIx-Class-Schema-Loader CPAN distribution.

Report information
The Basics
Id: 59640
Status: open
Priority: 0/
Queue: DBIx-Class-Schema-Loader

People
Owner: Nobody in particular
Requestors: maz [...] mlx.net
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)



Subject: Version 0.06+ and size info for integers and various other columns
Date: Fri, 23 Jul 2010 14:37:17 +0800
To: bug-DBIx-Class-Schema-Loader [...] rt.cpan.org
From: John Maslanik <maz [...] mlx.net>
Download (untitled) / with headers
text/plain 468b
Versions of DBIx::Class::Schema::Loader prior to Version 0.06 always included the "size" definition for mysql databases. Version 0.06+ no longer includes "size" definitions for some fields such as integers. This breaks any script that depends on the "size" definition. Could we either put the size definition back in or make it a configurable option? This breaks all my validation routines which depend on the "size" definition. Sincerely, John Maslanik
Subject: Re: [rt.cpan.org #59640] Version 0.06+ and size info for integers and various other columns
Date: Tue, 27 Jul 2010 17:36:51 -0400
To: John Maslanik via RT <bug-DBIx-Class-Schema-Loader [...] rt.cpan.org>
From: Rafael Kitover <rkitover [...] cpan.org>
Download (untitled) / with headers
text/plain 1.2k
Hi John, The "size" means the size of the type when declared in DDL, for example for VARCHAR(30) the "size" is 30. INTEGER and such do not have a size for DDL purposes, this is why it is omitted. Previous versions of ::Schema::Loader just set size to the size in bytes are reported by DBI, this was wrong and broke deploying the generated schemas with $schema->deploy using SQL::Translator. Current versions of ::Schema::Loader are much more SQL::Translator friendly and have accurate type information for the purposes of deployment and cross-deployment. If you need the old behavior, make a subclass of ::Schema::Loader::DBI::mysql that overrides _columns_info_for and pass that in as the "loader_class". On Fri, Jul 23, 2010 at 02:38:10AM -0400, John Maslanik via RT wrote: Show quoted text
> Versions of DBIx::Class::Schema::Loader prior to Version 0.06 always > included the "size" definition for mysql databases. Version 0.06+ no > longer includes "size" definitions for some fields such as integers. > This breaks any script that depends on the "size" definition. Could we > either put the size definition back in or make it a configurable > option? This breaks all my validation routines which depend on the > "size" definition. > > > Sincerely, > > John Maslanik > >
Download (untitled) / with headers
text/plain 290b
Hi, is this still an issue for you? The lack of size in bytes for integers etc. in the generated Result classes. I see you are asking for some sort of configuration option, so I'm not closing the ticket yet. What would this option do? Just set size to size in bytes rather than DDL size?
Subject: Re: [rt.cpan.org #59640] Version 0.06+ and size info for integers and various other columns
Date: Fri, 21 Jan 2011 13:42:42 +0800
To: bug-DBIx-Class-Schema-Loader [...] rt.cpan.org
From: John Maslanik <maz [...] mlx.net>
Download (untitled) / with headers
text/plain 646b
Actually, it's not an issue for me anymore because I have switched to generating my schema files from the database to generating the database from the schema files. Though I don't know if it may be an issue for others. On 1/21/2011 12:19 PM, Rafael Kitover via RT wrote: Show quoted text
> <URL: https://rt.cpan.org/Ticket/Display.html?id=59640> > > Hi, > > is this still an issue for you? The lack of size in bytes for integers > etc. in the generated Result classes. > > I see you are asking for some sort of configuration option, so I'm not > closing the ticket yet. > > What would this option do? Just set size to size in bytes rather than > DDL size?


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.