From notifications at github.com Sun Nov 20 20:48:40 2022 From: notifications at github.com (Veesh Goldman) Date: Sun, 20 Nov 2022 12:48:40 -0800 Subject: [DBIx-Class-Devel] [dbsrgits/dbix-class-schema-loader] Not recognising primary key automatically set with uuid_generate_v4() in PostgreSQL database [rt.cpan.org #143291] (Issue #28) Message-ID: Migrated from [rt.cpan.org#143291](https://rt.cpan.org/Ticket/Display.html?id=143291) (status was 'new') Requestors: * bruins at hal9000.net.au From bogus@does.not.exist.com Sun Nov 20 20:48:46 2022 From: bogus@does.not.exist.com () Date: Sun, 20 Nov 2022 20:48:46 -0000 Subject: No subject Message-ID: ``` Schema Loader version 0.07049 Database: postgresql/jammy 14+238 OS: Linux ubuntu-jammy 5.15.0-25-generic Example script: See below Table schema: See below Issue: repeated warnings that the perhaps I " forgot to set its 'is_auto_increment' attribute during add_columns()?" But Schema Loader doesn't recognise uuid_generate_v4() as setting the primary key when analysing existing table How do I get Schema Loader to recognise that there is a default value for the primary key? Example warning: DBIx::Class::Storage::DBI::insert(): Missing value for primary key column 'id' on POSTGRES_TABLE - perhaps you forgot to set its 'is_auto_increment' attribute during add_columns()? Treating 'id' implicitly as an autoinc, and attempting value retrieval at PERL_CODE_LINE Postgres Schema for Table "Invoice" Table "public.invoice" Column | Type | Collation | Nullable | Default ----------+-----------------------------+-----------+----------+-------------------- id | uuid | | not null | uuid_generate_v4() created | timestamp without time zone | | not null | now() modified | timestamp without time zone | | not null | now() amount | money | | not null | currency | character varying(3) | | not null | is_paid | boolean | | not null | false user_id | integer | | not null | Indexes: "invoice_pkey" PRIMARY KEY, btree (id) "invoice_unique_id" UNIQUE CONSTRAINT, btree (id) Calling script (functional part). use DBIx::Class::Schema::Loader qw/ make_schema_at /; make_schema_at( 'Series::Schema', { components => ["InflateColumn::DateTime"], debug => 0, dump_directory => './lib', moniker_map => \&moniker, }, [ $sql_db->{db_dsn}, $sql_db->{db_username}, $sql_db->{db_password}, {} ], ); sub moniker { my $table = shift; my $result; if ( $table eq 'user_table' ) { $result = 'User'; } elsif ( $table eq 'group_table' ) { $result = 'Group'; } else { $result = join q{}, map {ucfirst} split /_/, $table; } return $result; } ## end sub moniker ``` -- Reply to this email directly or view it on GitHub: https://github.com/dbsrgits/dbix-class-schema-loader/issues/28 You are receiving this because you are subscribed to this thread. Message ID: ----==_mimepart_637a92a8ee177_9167c6701800544 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

Migrated from rt.cpan.org#143291 (status was 'new')

Requestors:

From bruins at hal9000.net.au on 2022-06-14 10:40:43
:

Schema Loader version 0.07049
Database: postgresql/jammy 14+238
OS: Linux ubuntu-jammy 5.15.0-25-generic
Example script: See below
Table schema:  See below

Issue: repeated warnings that the perhaps I " forgot to set its 'is_auto_increment' attribute during add_columns()?"
But Schema Loader doesn't recognise uuid_generate_v4() as setting the primary key when analysing existing table

How do I get Schema Loader to recognise that there is a default value for the primary key?


Example warning:

DBIx::Class::Storage::DBI::insert(): Missing value for primary key column 'id' on POSTGRES_TABLE - perhaps you forgot to set its 'is_auto_increment' attribute during add_columns()? Treating 'id' implicitly as an autoinc, and attempting value retrieval at PERL_CODE_LINE


Postgres Schema for Table "Invoice"

                               Table "public.invoice"
  Column  |            Type             | Collation | Nullable |      Default
----------+-----------------------------+-----------+----------+--------------------
 id       | uuid                        |           | not null | uuid_generate_v4()
 created  | timestamp without time zone |           | not null | now()
 modified | timestamp without time zone |           | not null | now()
 amount   | money                       |           | not null |
 currency | character varying(3)        |           | not null |
 is_paid  | boolean                     |           | not null | false
 user_id  | integer                     |           | not null |
Indexes:
    "invoice_pkey" PRIMARY KEY, btree (id)
    "invoice_unique_id" UNIQUE CONSTRAINT, btree (id)





Calling script (functional part).

use DBIx::Class::Schema::Loader qw/ make_schema_at /;
make_schema_at(
    'Series::Schema',
    {   components     => ["InflateColumn::DateTime"],
        debug          => 0,
        dump_directory => './lib',
        moniker_map    => \&moniker,

    },
    [ $sql_db->{db_dsn}, $sql_db->{db_username}, $sql_db->{db_password}, {} ],
);

sub moniker {
    my $table = shift;
    my $result;
    if ( $table eq 'user_table' ) {
        $result = 'User';
    }
    elsif ( $table eq 'group_table' ) {
        $result = 'Group';
    }
    else {
        $result = join q{}, map {ucfirst} split /_/, $table;
    }
    return $result;
} ## end sub moniker


Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.Message ID: <dbsrgits/dbix-class-schema-loader/issues/28@github.com>

----==_mimepart_637a92a8ee177_9167c6701800544-- From notifications at github.com Sun Nov 20 20:48:51 2022 From: notifications at github.com (Veesh Goldman) Date: Sun, 20 Nov 2022 12:48:51 -0800 Subject: [DBIx-Class-Devel] [dbsrgits/dbix-class-schema-loader] Postgres Inheritance [rt.cpan.org #39087] (Issue #29) Message-ID: Migrated from [rt.cpan.org#39087](https://rt.cpan.org/Ticket/Display.html?id=39087) (status was 'new') Requestors: * MAROS at cpan.org Attachments: * [dbix-class-schema-loader_4794_map.diff](https://rt.cpan.org/Ticket/Attachment/506060/251584/dbix-class-schema-loader_4794_map.diff) From bogus@does.not.exist.com Sun Nov 20 20:48:46 2022 From: bogus@does.not.exist.com () Date: Sun, 20 Nov 2022 20:48:46 -0000 Subject: No subject Message-ID: ``` I have written a patch to support the postgres inheritance feature based on http://dev.catalystframework.org/repos/bast/branches/DBIx-Class-Schema-Loader/current (Revision: 4794) The additional option 'respect_inheritance' creates schema classes that use the same inheritance/parents as in postgres. With 'inheritance_schema_map' it is even possible to create correctly inherited tables across multiple schema. I would really appreciate it to see this patch in a future release. ``` -- Reply to this email directly or view it on GitHub: https://github.com/dbsrgits/dbix-class-schema-loader/issues/29 You are receiving this because you are subscribed to this thread. Message ID: ----==_mimepart_637a92b37fe37_63a2c67019096fa Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

Migrated from rt.cpan.org#39087 (status was 'new')

Requestors:

Attachments:

From maros at cpan.org on 2008-09-08 12:36:10
:

I have written a patch to support the postgres inheritance feature based
on
http://dev.catalystframework.org/repos/bast/branches/DBIx-Class-Schema-Loader/current
(Revision: 4794)

The additional option 'respect_inheritance' creates schema classes that
use the same inheritance/parents as in postgres. With
'inheritance_schema_map' it is even possible to create correctly
inherited tables across multiple schema.

I would really appreciate it to see this patch in a future release.


Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.Message ID: <dbsrgits/dbix-class-schema-loader/issues/29@github.com>

----==_mimepart_637a92b37fe37_63a2c67019096fa-- From notifications at github.com Sun Nov 20 20:49:00 2022 From: notifications at github.com (Veesh Goldman) Date: Sun, 20 Nov 2022 12:49:00 -0800 Subject: [DBIx-Class-Devel] [dbsrgits/dbix-class-schema-loader] dbicdump and podweaver [rt.cpan.org #68752] (Issue #30) Message-ID: Migrated from [rt.cpan.org#68752](https://rt.cpan.org/Ticket/Display.html?id=68752) (status was 'new') Requestors: * xenoterracide at gmail.com From bogus@does.not.exist.com Sun Nov 20 20:48:46 2022 From: bogus@does.not.exist.com () Date: Sun, 20 Nov 2022 20:48:46 -0000 Subject: No subject Message-ID: ```=0D ---------- Forwarded message ----------=0D From: Caleb Cushing =0D Date: Wed, Jun 8, 2011 at 3:02 PM=0D Subject: dbicdump and podweaver=0D To: bugs-dbix-class-schema-loader-base at rt.cpan.org=0D =0D =0D so I'm personally for a weaver dbic plugin an example of an addon that=0D= one could put in weaver.ini then you add the SeeAlso to your=0D weaver.ini and the section will automatically be added to all the pod=0D in your dzil distribution. This seems to me like it'd be the right way=0D= to add the ACCESSORS section. In which case then dbicdump wouldn't=0D need anything, just tell it not to generate pod, and let people do it=0D with weaver entirely.=0D =0D http://search.cpan.org/~apocal/Pod-Weaver-Section-SeeAlso-1.002/lib/Pod/W= eaver/Section/SeeAlso.pm=0D =0D [14:22] ccushing: what doesn't podweaver like about my POD?=0D [14:24] *** GumbyNET5 gives channel operator privileges to Bender.=0D [14:25] Caelum: oh, I'm not sure it's entirely all=0D podweaver but normally when you use dzil you don't have a NAME=0D section, you have a # ABSTRACT and it builds out NAME and a whole=0D bunch of pod stuff=0D [14:26] actually if the pod was below the md5sum I could=0D just modify it=0D [14:29] ccushing: I'll look into adding an option to generate=0D= podweaver-compatible POD=0D [14:31] Caelum: actually maye just need an option not to=0D include NAME =C3=82=C2=A0I think that's the only thing that needs to be=0D= removed...=0D [14:31] ccushing: which dzil pluginbundle do you use?=0D [14:32] usually @basic=0D [14:33] ccushing: what does NAME need to be replaced by?=0D [14:34] ccushing: ABSTRACT?=0D [14:34] i guess ABSTRACT is the landlord of xaven, apart of the=0D= infobot development team at http://infobot.org or=0D mailto:adam at infobot.org=0D [14:34] # ABSTRACT: description=0D [14:35] Caelum: ya=0D [14:35] ccushing: ok, thanks=0D [14:35] I personally usually put my pod at the end of my=0D files so that the dzil build doesn't change the code lines=0D [14:35] because podweaver will otherwise throw all the pod=0D like below # ABSTRACT:=0D [14:36] ccushing: I'll have the podweaver mode do that then=0D [14:36] right, not sure how that affects the md5sum stuff thou= gh=0D [14:37] course for all it matters to me personally... you=0D could throw pod below that...=0D [14:37] ccushing: but then how do you update it=0D [14:38] yeah there's the problem... because usually you=0D need to put code below that md5 some so no matter what you end up with=0D= code changing spots with pod in the end=0D [14:38] idk=0D [14:38] it's a no win situation=0D [14:38] some people won't care where the pod ends up=0D [14:39] ccushing: what if s::l would run podweaver itself?=0D [14:39] ccushing: is there a marker for podweaver to say=0D "already ran" or something=0D [14:39] hmm=0D [14:39] idk=0D [14:39] better question for rjbs... though maybe you could=0D write a module that generates all this documentation later=0D [14:40] and has a marker=0D [14:40] ccushing: ok, could I ask you to open an RT for me=0D please? You can just paste the irc log if you want=0D [14:40] like # DBIC_ACCESSORS=0D [14:40] and then people can add that to weaver.ini=0D [14:40] and just exclude pod, include that, and you've got=0D it in the final build=0D [14:41] yeah=0D [14:42] ccushing: we could also exclude POD from the md5sum=0D [14:43] ccushing: that's pretty easy to do=0D [14:43] Caelum: well the more I think about it... just=0D having it generated by podweaver later... without anyting added to the=0D= files would be a great idea=0D =0D --=0D Caleb Cushing=0D =0D http://xenoterracide.com=0D =0D =0D =0D -- =0D Caleb Cushing=0D =0D http://xenoterracide.com=0D ```=0D =0D From bogus@does.not.exist.com Sun Nov 20 20:48:46 2022 From: bogus@does.not.exist.com () Date: Sun, 20 Nov 2022 20:48:46 -0000 Subject: No subject Message-ID: ```=0D further reflection says, if you create a weaver plugin...=0D =0D for dbicdump just have it add the following for a dzil option=0D =0D # ABSTRACT: class::path=0D =0D below the md5sum, doing it below makes it easily changed to an actual=0D description if someone wants. Also it shouldn't really need auto=0D updating after initial generation.=0D =0D -- =0D Caleb Cushing=0D =0D http://xenoterracide.com=0D ```=0D =0D =0D -- =0D Reply to this email directly or view it on GitHub:=0D https://github.com/dbsrgits/dbix-class-schema-loader/issues/30=0D You are receiving this because you are subscribed to this thread.=0D =0D Message ID: = ----==_mimepart_637a92bcadfb9_7e9fc67021745a6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

=0D

Migrated from rt.cpan.org#68752 (status was 'n= ew')

=0D

Requestors:

=0D =0D

From xenoterra= cide at gmail.com on 2011-06-10 16:42:32
=0D :

=0D
---------- Forward=
ed message ----------=0D
From: Caleb Cushing <xenoterracide at gmail.com>=0D
Date: Wed, Jun 8, 2011 at 3:02 PM=0D
Subject: dbicdump and podweaver=0D
To: bugs-dbix-class-schema-loader-base at rt.cpan.org=0D
=0D
=0D
so I'm personally for a weaver dbic plugin an example of an addon that=0D=

one could put in weaver.ini then you add the SeeAlso to your=0D
weaver.ini and the section will automatically be added to all the pod=0D
in your dzil distribution. This seems to me like it'd be the right way=0D=

to add the ACCESSORS section. In which case then dbicdump wouldn't=0D
need anything, just tell it not to generate pod, and let people do it=0D
with weaver entirely.=0D
=0D
http://search.cpan.org/~apocal/Pod-Weaver-Section-SeeAlso-1.002/lib/Pod/W=
eaver/Section/SeeAlso.pm=0D
=0D
[14:22] <Caelum> ccushing: what doesn't podweaver like about my POD=
?=0D
[14:24] *** GumbyNET5 gives channel operator privileges to Bender.=0D
[14:25] <ccushing> Caelum: oh, I'm not sure it's entirely all=0D
podweaver but normally when you use dzil you don't have a NAME=0D
section, you have a # ABSTRACT and it builds out NAME and a whole=0D
bunch of pod stuff=0D
[14:26] <ccushing> actually if the pod was below the md5sum I could=
=0D
just modify it=0D
[14:29] <Caelum> ccushing: I'll look into adding an option to gener=
ate=0D
podweaver-compatible POD=0D
[14:31] <ccushing> Caelum: actually maye just need an option not to=
=0D
include NAME =C3=82=C2=A0I think that's the only thing that needs to be=0D=

removed...=0D
[14:31] <Caelum> ccushing: which dzil pluginbundle do you use?=0D
[14:32] <ccushing> usually @basic=0D
[14:33] <Caelum> ccushing: what does NAME need to be replaced by?=0D=

[14:34] <Caelum> ccushing: ABSTRACT?=0D
[14:34] <purl> i guess ABSTRACT is the landlord of xaven, apart of =
the=0D
infobot development team at http://infobot.org or=0D
mailto:adam at infobot.org=0D
[14:34] <ccushing> # ABSTRACT: description=0D
[14:35] <ccushing> Caelum: ya=0D
[14:35] <Caelum> ccushing: ok, thanks=0D
[14:35] <ccushing> I personally usually put my pod at the end of my=
=0D
files so that the dzil build doesn't change the code lines=0D
[14:35] <ccushing> because podweaver will otherwise throw all the p=
od=0D
like below # ABSTRACT:=0D
[14:36] <Caelum> ccushing: I'll have the podweaver mode do that the=
n=0D
[14:36] <ccushing> right, not sure how that affects the md5sum stuf=
f though=0D
[14:37] <ccushing> course for all it matters to me personally... yo=
u=0D
could throw pod below that...=0D
[14:37] <Caelum> ccushing: but then how do you update it=0D
[14:38] <ccushing> yeah there's the problem... because usually you=0D=

need to put code below that md5 some so no matter what you end up with=0D=

code changing spots with pod in the end=0D
[14:38] <ccushing> idk=0D
[14:38] <ccushing> it's a no win situation=0D
[14:38] <ccushing> some people won't care where the pod ends up=0D
[14:39] <Caelum> ccushing: what if s::l would run podweaver itself?=
=0D
[14:39] <Caelum> ccushing: is there a marker for podweaver to say=0D=

"already ran" or something=0D
[14:39] <ccushing> hmm=0D
[14:39] <ccushing> idk=0D
[14:39] <ccushing> better question for rjbs... though maybe you cou=
ld=0D
write a module that generates all this documentation later=0D
[14:40] <ccushing> and has a marker=0D
[14:40] <Caelum> ccushing: ok, could I ask you to open an RT for me=
=0D
please? You can just paste the irc log if you want=0D
[14:40] <ccushing> like # DBIC_ACCESSORS=0D
[14:40] <ccushing> and then people can add that to weaver.ini=0D
[14:40] <ccushing> and just exclude pod, include that, and you've g=
ot=0D
it in the final build=0D
[14:41] <ccushing> yeah=0D
[14:42] <Caelum> ccushing: we could also exclude POD from the md5su=
m=0D
[14:43] <Caelum> ccushing: that's pretty easy to do=0D
[14:43] <ccushing> Caelum: well the more I think about it... just=0D=

having it generated by podweaver later... without anyting added to the=0D=

files would be a great idea=0D
=0D
--=0D
Caleb Cushing=0D
=0D
http://xenoterracide.com=0D
=0D
=0D
=0D
-- =0D
Caleb Cushing=0D
=0D
http://xenoterracide.com=0D
=0D

From xenoterra= cide at gmail.com on 2011-06-10 16:55:17
=0D :

=0D
further reflection=
 says, if you create a weaver plugin...=0D
=0D
for dbicdump just have it add the following for a dzil option=0D
=0D
# ABSTRACT: class::path=0D
=0D
below the md5sum, doing it below makes it easily changed to an actual=0D
description if someone wants. Also it shouldn't really need auto=0D
updating after initial generation.=0D
=0D
-- =0D
Caleb Cushing=0D
=0D
http://xenoterracide.com=0D
=0D =0D

&m= dash;
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receivi= ng this because you are subscribed to this thread.3D""Message I= D: <dbsrgits/dbix-class-schema-loader/issues/30@github.com>

=0D = ----==_mimepart_637a92bcadfb9_7e9fc67021745a6-- From notifications at github.com Sun Nov 20 20:49:07 2022 From: notifications at github.com (Veesh Goldman) Date: Sun, 20 Nov 2022 12:49:07 -0800 Subject: [DBIx-Class-Devel] [dbsrgits/dbix-class-schema-loader] Encode S::L dump options within the Schema.pm [rt.cpan.org #70831] (Issue #31) Message-ID: Migrated from [rt.cpan.org#70831](https://rt.cpan.org/Ticket/Display.html?id=70831) (status was 'new') Requestors: * ribasushi at leporine.io From bogus@does.not.exist.com Sun Nov 20 20:48:46 2022 From: bogus@does.not.exist.com () Date: Sun, 20 Nov 2022 20:48:46 -0000 Subject: No subject Message-ID: ``` As per your request filing it here: The idea is to make a machine-parseable comment (Data::Dumper would work just fine) at the top of the schema, which is part of the md5 (disallowing direct user manipulation). Then once you have a schema, when you redump all the defaults you did not supply in the call (or on the cli) are taken from parsing back this comment. So in essence editing the options is facilitated by a re-dump with new options which S::L respects. ``` -- Reply to this email directly or view it on GitHub: https://github.com/dbsrgits/dbix-class-schema-loader/issues/31 You are receiving this because you are subscribed to this thread. Message ID: ----==_mimepart_637a92c3c2c14_75a3c6702126183 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

Migrated from rt.cpan.org#70831 (status was 'new')

Requestors:

From ribasushi at leporine.io on 2011-09-09 04:10:00
:

As per your request filing it here:

The idea is to make a machine-parseable comment (Data::Dumper would work
just fine) at the top of the schema, which is part of the md5
(disallowing direct user manipulation). Then once you have a schema,
when you redump all the defaults you did not supply in the call (or on
the cli) are taken from parsing back this comment. So in essence editing
the options is facilitated by a re-dump with new options which S::L
respects.


Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.Message ID: <dbsrgits/dbix-class-schema-loader/issues/31@github.com>

----==_mimepart_637a92c3c2c14_75a3c6702126183-- From notifications at github.com Sun Nov 20 20:49:14 2022 From: notifications at github.com (Veesh Goldman) Date: Sun, 20 Nov 2022 12:49:14 -0800 Subject: [DBIx-Class-Devel] [dbsrgits/dbix-class-schema-loader] calling make_schema_at modifes @INC [rt.cpan.org #81742] (Issue #32) Message-ID: Migrated from [rt.cpan.org#81742](https://rt.cpan.org/Ticket/Display.html?id=81742) (status was 'new') Requestors: * JDS at cpan.org From bogus@does.not.exist.com Sun Nov 20 20:48:46 2022 From: bogus@does.not.exist.com () Date: Sun, 20 Nov 2022 20:48:46 -0000 Subject: No subject Message-ID: ``` Tested under Win32 strawberryperl 5.14.2.1 on a 64bit Windows 7 machine. After a call to make_schema_at, the current directory '.' disappears from @INC. As an example consider the following method: sub dump_schema { my $attrs = { debug => 0, dump_directory => '.', exclude => qr/(?^:\bBIN)/ }; my $connect_info = [ $dsn, $user, $password ]; push @$connect_info, { on_connect_do => 'PRAGMA foreign_keys = ON' }; make_schema_at( 'TDG::Schema', $attrs, $connect_info ); eval { require TDG::Schema; TDG::Schema->import(); 1; } or do { my $error = $@; croak $error; }; $dbic_schema = TDG::Schema->connect( $dsn, $user, $password, '' ); } The error I got when executing it (using a connection to a SQLite database) was: Can't locate TDG/Schema.pm in @INC... Before calling make_schema_at, we have: DB<2> x @INC 0 'C:/Dwimperl/perl/site/lib' 1 'C:/Dwimperl/perl/vendor/lib' 2 'C:/Dwimperl/perl/lib' 3 '.' afterwards: DB<3> x @INC 0 'C:/Dwimperl/perl/site/lib' 1 'C:/Dwimperl/perl/vendor/lib' 2 'C:/Dwimperl/perl/lib' Which explains the error. ``` -- Reply to this email directly or view it on GitHub: https://github.com/dbsrgits/dbix-class-schema-loader/issues/32 You are receiving this because you are subscribed to this thread. Message ID: ----==_mimepart_637a92ca7bdf4_3ae1c67023115c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

Migrated from rt.cpan.org#81742 (status was 'new')

Requestors:

From jds at cpan.org on 2012-12-06 13:40:06
:

Tested under Win32 strawberryperl 5.14.2.1 on a 64bit Windows 7 machine.

After a call to make_schema_at, the current directory '.' disappears
from @INC.

As an example consider the following method:

sub dump_schema {	
	my $attrs = {
		debug          => 0,
		dump_directory => '.',
		exclude => qr/(?^:\bBIN)/
	};
	
	my $connect_info = [ $dsn, $user, $password ];
	push @$connect_info, { on_connect_do => 'PRAGMA foreign_keys = ON' };
	make_schema_at( 'TDG::Schema', $attrs, $connect_info );

    eval {
        require TDG::Schema;
        TDG::Schema->import();
        1;
    } or do {
        my $error = $@;
        croak $error;
    };

    $dbic_schema = TDG::Schema->connect( $dsn, $user, $password, '' );

}

The error I got when executing it (using a connection to a SQLite
database) was:

Can't locate TDG/Schema.pm in @INC...

Before calling make_schema_at, we have:

  DB<2> x @INC
0  'C:/Dwimperl/perl/site/lib'
1  'C:/Dwimperl/perl/vendor/lib'
2  'C:/Dwimperl/perl/lib'
3  '.'

afterwards:

  DB<3> x @INC
0  'C:/Dwimperl/perl/site/lib'
1  'C:/Dwimperl/perl/vendor/lib'
2  'C:/Dwimperl/perl/lib'

Which explains the error.



Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.Message ID: <dbsrgits/dbix-class-schema-loader/issues/32@github.com>

----==_mimepart_637a92ca7bdf4_3ae1c67023115c-- From notifications at github.com Sun Nov 20 20:49:21 2022 From: notifications at github.com (Veesh Goldman) Date: Sun, 20 Nov 2022 12:49:21 -0800 Subject: [DBIx-Class-Devel] [dbsrgits/dbix-class-schema-loader] getting this Error [rt.cpan.org #97674] (Issue #33) Message-ID: Migrated from [rt.cpan.org#97674](https://rt.cpan.org/Ticket/Display.html?id=97674) (status was 'new') Requestors: * satish_mp at spanservices.com From bogus@does.not.exist.com Sun Nov 20 20:48:46 2022 From: bogus@does.not.exist.com () Date: Sun, 20 Nov 2022 20:48:46 -0000 Subject: No subject Message-ID: ``` Hello Team, I am trying to build a small demo application using Mojolcious and DBIx::Class. Here I am trying to run this script, which I have attached for reference. D:\learning\perl_practice_scripts\tech_utsav>perl script\generate_schema 0.07040 Bizarre copy of UNKNOWN in scalar assignment at C:/Dwimperl/perl/site/lib/DBIx /Class/Schema/Loader/Base.pm line 1059. and the perl.exe gets hanged, stops working. Please let me know your inputs or suggestions. I have referred this link: "https://github.com/tempire/MojoExample/" I have working schema for both sqlite3 and mysql. generate_script is something like this: ##-----------------------------------------------------------## use Modern::Perl; use DBIx::Class::Schema::Loader 'make_schema_at'; my $DEBUG = @ARGV and $ARGV[0] =~ /^\-[\-]*v/; say $DBIx::Class::Schema::Loader::VERSION ;#if $DEBUG; my @dsn = 'dbi:SQLite:dbname=techutsav.db'; my $options = { debug => $DEBUG, dump_directory => 'lib', components => [qw/InflateColumn::DateTime /], generate_pod => 0, }; make_schema_at(Schema => $options, \@dsn); ##----------------------------------------------------------- Regards, Satish. DISCLAIMER: This email message and all attachments are confidential and may contain information that is Privileged, Confidential or exempt from disclosure under applicable law. If you are not the intended recipient, you are notified that any dissemination, distribution or copying of this email is strictly prohibited. If you have received this email in error, please notify us immediately by return email to mailadmin at spanservices.com and destroy the original message. Opinions, conclusions and other information in this message that do not relate to the official of SPAN, shall be understood to be nether given nor endorsed by SPAN. ``` -- Reply to this email directly or view it on GitHub: https://github.com/dbsrgits/dbix-class-schema-loader/issues/33 You are receiving this because you are subscribed to this thread. Message ID: ----==_mimepart_637a92d1f2594_3dd2c6701893780 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

Migrated from rt.cpan.org#97674 (status was 'new')

Requestors:

From satish_mp at spanservices.com on 2014-08-01 16:30:49
:

Hello Team,

I am trying to build a small demo application using Mojolcious and
DBIx::Class. 
Here I am trying to run this script, which I have attached for reference.

D:\learning\perl_practice_scripts\tech_utsav>perl script\generate_schema
0.07040
Bizarre copy of UNKNOWN in scalar assignment at C:/Dwimperl/perl/site/lib/DBIx
/Class/Schema/Loader/Base.pm line 1059.

and the perl.exe gets hanged, stops working.

Please let me know your inputs or suggestions.
I have referred this link: "https://github.com/tempire/MojoExample/"

I have working schema for both sqlite3 and mysql. generate_script is something
like this:
##-----------------------------------------------------------##
use Modern::Perl;
use DBIx::Class::Schema::Loader 'make_schema_at';

my $DEBUG = @ARGV and $ARGV[0] =~ /^\-[\-]*v/;

say $DBIx::Class::Schema::Loader::VERSION ;#if $DEBUG;
my @dsn = 'dbi:SQLite:dbname=techutsav.db';

my $options = {
  debug          => $DEBUG,
  dump_directory => 'lib',
  components     => [qw/InflateColumn::DateTime /],
  generate_pod   => 0,
};
make_schema_at(Schema => $options, \@dsn);
##-----------------------------------------------------------

Regards,
Satish.

DISCLAIMER: This email message and all attachments are confidential and may
contain information that is Privileged, Confidential or exempt from disclosure
under applicable law. If you are not the intended recipient, you are notified
that any dissemination, distribution or copying of this email is strictly
prohibited.  If you have received this email in error, please notify us
immediately by return email to mailadmin at spanservices.com and destroy the
original message.  Opinions, conclusions and other information in this message
that do not relate to the official of SPAN, shall be understood to be nether
given nor endorsed by SPAN.


Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.Message ID: <dbsrgits/dbix-class-schema-loader/issues/33@github.com>

----==_mimepart_637a92d1f2594_3dd2c6701893780-- From notifications at github.com Sun Nov 20 20:49:30 2022 From: notifications at github.com (Veesh Goldman) Date: Sun, 20 Nov 2022 12:49:30 -0800 Subject: [DBIx-Class-Devel] [dbsrgits/dbix-class-schema-loader] DBIx::Class::Schema::Loader::DBI::DB2 Class // Getting relationship fail [rt.cpan.org #100287] (Issue #34) Message-ID: Migrated from [rt.cpan.org#100287](https://rt.cpan.org/Ticket/Display.html?id=100287) (status was 'new') Requestors: * Frank.Biermann at gad.de From bogus@does.not.exist.com Sun Nov 20 20:48:46 2022 From: bogus@does.not.exist.com () Date: Sun, 20 Nov 2022 20:48:46 -0000 Subject: No subject Message-ID: ``` Hello Support Team, I would like to make the following proposal. In the function _table_fk_info we should select the fields with rtrim. Some schema have subsequent blanks and later on key values do not exist in the object hashref. => Searching for relationship will fail. SELECT tc.constname, sr.reftabschema, sr.reftabname, kcu.colname, rkcu.colname, kcu.colseq, sr.deleterule, sr.updaterule to SELECT tc.constname, rtrim(sr.reftabschema), sr.reftabname, kcu.colname, rkcu.colname, kcu.colseq, sr.deleterule, sr.updaterule Kind regards Frank Biermann ``` -- Reply to this email directly or view it on GitHub: https://github.com/dbsrgits/dbix-class-schema-loader/issues/34 You are receiving this because you are subscribed to this thread. Message ID: ----==_mimepart_637a92da40b6c_c19c67016223f8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

Migrated from rt.cpan.org#100287 (status was 'new')

Requestors:

From frank.biermann at gad.de on 2014-11-12 12:01:49
:

Hello Support Team,

I would like to make the following proposal.

In the function _table_fk_info we should select the fields with rtrim. 
Some schema have subsequent blanks and later on key values do not exist in 
the object hashref.

=> Searching for relationship will fail.


SELECT tc.constname, sr.reftabschema, sr.reftabname,
       kcu.colname, rkcu.colname, kcu.colseq,
       sr.deleterule, sr.updaterule

to

SELECT tc.constname, rtrim(sr.reftabschema), sr.reftabname,
       kcu.colname, rkcu.colname, kcu.colseq,
       sr.deleterule, sr.updaterule


Kind regards

Frank Biermann


Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.Message ID: <dbsrgits/dbix-class-schema-loader/issues/34@github.com>

----==_mimepart_637a92da40b6c_c19c67016223f8-- From notifications at github.com Sun Nov 20 20:49:37 2022 From: notifications at github.com (Veesh Goldman) Date: Sun, 20 Nov 2022 12:49:37 -0800 Subject: [DBIx-Class-Devel] [dbsrgits/dbix-class-schema-loader] MSSQL 'timestamp' columns should be treated like blobs [rt.cpan.org #113465] (Issue #35) Message-ID: Migrated from [rt.cpan.org#113465](https://rt.cpan.org/Ticket/Display.html?id=113465) (status was 'new') Requestors: * vanstyn at cpan.org From bogus@does.not.exist.com Sun Nov 20 20:48:46 2022 From: bogus@does.not.exist.com () Date: Sun, 20 Nov 2022 20:48:46 -0000 Subject: No subject Message-ID: ``` MSSQL 'timestamp' columns are not actually timestamps, they are 8-byte blobs which store an incrementing version value whenever the row is changed, but do not actually store any date/time information whatsoever (in fact, in later versions of MSSQL they have started calling these 'RowVersion'). Currently S::L reads these as data_type => 'timestamp' but ribasushi suggested that it might be better for these to be treated as blobs since this is closer to what they actually are. He asked me to open this ticket and paste the below IRC chat log... ** scrollback from IRC ** <--snip--> vanstyn: are you certain it is a blob and it's not DBI/S::L doing switching on you? well, navicat shows it as a BLOB ... but... that might just be how it is exposed... yeah, this seems very much like what it is... thanks! vanstyn: I'd run S::L against it to make sure - it doesn't seem to have a special handling to do timestamp => blob (by a cursory browse of source) vanstyn: but if it *is* the timestamp thing - it is rather very common, especially among .net/asp software yeah, I did run it through S::L, and it shows data_type => 'timestamp' then that's what it is ;) navicat is DWIMing for you (because it is effectively a blob) in fact... and it also set inflate_datetime => 0, which makes me think S::L knows this * robsco (~robsco at cpc65125-nmal16-2-0-cust242.19-2.cable.virginm.net) has joined #dbix-class so, yeah, mystery solved... ilmari: ^^ perhaps S::L should s/timestamp/blob/ and shove an extra metadatakey of "was such and such datatype" ilmari: so that this confusion doesn't happen again ( for MSSQL obv. ) * stelf|pc (~stelf at 188-254-163-177.sf.ddns.bulsat.com) has joined #dbix-class * stelf|pc_ has quit (Ping timeout: 360 seconds) vanstyn: and yes, Caelum did consider it, but added support in an ass-backwards way: https://github.com/dbsrgits/dbix-class-schema-loader/commit/81ade4d9da9b861849c51894b7e8f380e74192d4#diff-c3693ab39251ec52efb7839c3c0ca409R122 ribasushi: thanks again! vanstyn: can you open a ticket against S::L with the conversation above so it doesn't get lost? ``` -- Reply to this email directly or view it on GitHub: https://github.com/dbsrgits/dbix-class-schema-loader/issues/35 You are receiving this because you are subscribed to this thread. Message ID: ----==_mimepart_637a92e127080_7ed7c67017250af Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

Migrated from rt.cpan.org#113465 (status was 'new')

Requestors:

From vanstyn at cpan.org on 2016-03-30 22:06:35
:

MSSQL 'timestamp' columns are not actually timestamps, they are 8-byte blobs which store an incrementing version value whenever the row is changed, but do not actually store any date/time information whatsoever (in fact, in later versions of MSSQL they have started calling these 'RowVersion').

Currently S::L reads these as data_type => 'timestamp' but ribasushi suggested that it might be better for these to be treated as blobs since this is closer to what they actually are. He asked me to open this ticket and paste the below IRC chat log...


** scrollback from IRC **

<--snip-->
<ribasushi> vanstyn: are you certain it is a blob and it's not DBI/S::L doing switching on you? 
<vanstyn> well, navicat shows it as a BLOB ...
<vanstyn> but... that might just be how it is exposed... yeah, this seems very much like what it is... thanks!
<ribasushi> vanstyn: I'd run S::L against it to make sure - it doesn't seem to have a special handling to do timestamp => blob (by a cursory browse of source)
<ribasushi> vanstyn: but if it *is* the timestamp thing - it is rather very common, especially among .net/asp software
<vanstyn> yeah, I did run it through S::L, and it shows data_type => 'timestamp'
<ribasushi> then that's what it is ;)
<ribasushi> navicat is DWIMing for you (because it is effectively a blob)
<ribasushi> in fact...
<vanstyn> and it also set inflate_datetime => 0, which makes me think S::L knows this
* robsco (~robsco at cpc65125-nmal16-2-0-cust242.19-2.cable.virginm.net) has joined #dbix-class
<vanstyn> so, yeah, mystery solved...
<ribasushi> ilmari: ^^ perhaps S::L should s/timestamp/blob/ and shove an extra metadatakey of "was such and such datatype"
<ribasushi> ilmari: so that this confusion doesn't happen again
<ribasushi> ( for MSSQL obv. )
* stelf|pc (~stelf at 188-254-163-177.sf.ddns.bulsat.com) has joined #dbix-class
* stelf|pc_ has quit (Ping timeout: 360 seconds)
<ribasushi> vanstyn: and yes, Caelum did consider it, but added support in an ass-backwards way: https://github.com/dbsrgits/dbix-class-schema-loader/commit/81ade4d9da9b861849c51894b7e8f380e74192d4#diff-c3693ab39251ec52efb7839c3c0ca409R122
<vanstyn> ribasushi: thanks again!
<ribasushi> vanstyn: can you open a ticket against S::L with the conversation above so it doesn't get lost?


Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.Message ID: <dbsrgits/dbix-class-schema-loader/issues/35@github.com>

----==_mimepart_637a92e127080_7ed7c67017250af-- From notifications at github.com Sun Nov 20 20:49:43 2022 From: notifications at github.com (Veesh Goldman) Date: Sun, 20 Nov 2022 12:49:43 -0800 Subject: [DBIx-Class-Devel] [dbsrgits/dbix-class-schema-loader] use parent instead of base [rt.cpan.org #117958] (Issue #36) Message-ID: Migrated from [rt.cpan.org#117958](https://rt.cpan.org/Ticket/Display.html?id=117958) (status was 'new') Requestors: * gjungwirth at sipwise.com From bogus@does.not.exist.com Sun Nov 20 20:48:46 2022 From: bogus@does.not.exist.com () Date: Sun, 20 Nov 2022 20:48:46 -0000 Subject: No subject Message-ID: ``` It appears to me that nowadays "use parent" ist recommended over "use base". Can we have an option (or switch fully) to "use parent" in the generated schema? ``` -- Reply to this email directly or view it on GitHub: https://github.com/dbsrgits/dbix-class-schema-loader/issues/36 You are receiving this because you are subscribed to this thread. Message ID: ----==_mimepart_637a92e7c5cf8_67c9c6701796049 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

Migrated from rt.cpan.org#117958 (status was 'new')

Requestors:

From gjungwirth at sipwise.com on 2016-09-19 12:08:38
:

It appears to me that nowadays "use parent" ist recommended over "use base". Can we have an option (or switch fully) to "use parent" in the generated schema?


Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.Message ID: <dbsrgits/dbix-class-schema-loader/issues/36@github.com>

----==_mimepart_637a92e7c5cf8_67c9c6701796049-- From notifications at github.com Sun Nov 20 20:49:50 2022 From: notifications at github.com (Veesh Goldman) Date: Sun, 20 Nov 2022 12:49:50 -0800 Subject: [DBIx-Class-Devel] [dbsrgits/dbix-class-schema-loader] postgress-specific test fails when test schema has preexisting tables in it [rt.cpan.org #118168] (Issue #37) Message-ID: Migrated from [rt.cpan.org#118168](https://rt.cpan.org/Ticket/Display.html?id=118168) (status was 'new') Requestors: * ribasushi at leporine.io From bogus@does.not.exist.com Sun Nov 20 20:48:46 2022 From: bogus@does.not.exist.com () Date: Sun, 20 Nov 2022 20:48:46 -0000 Subject: No subject Message-ID: ``` This was fixed in a gist a while ago, but was never applied. I vaguely recall it was some sort of limiter that was missing on the schema-test, but do not have the exact incantation. To reproduce: set DBICTEST_PG_(DSN/USER/PASS) cpanm --reinstall DBIx::Class::ResultSource::MultipleTableInheritance cpanm --reinstall DBIx::Class::Schema::Loader ``` -- Reply to this email directly or view it on GitHub: https://github.com/dbsrgits/dbix-class-schema-loader/issues/37 You are receiving this because you are subscribed to this thread. Message ID: ----==_mimepart_637a92eee526a_8c99c670570f2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

Migrated from rt.cpan.org#118168 (status was 'new')

Requestors:

From ribasushi at leporine.io on 2016-09-30 15:12:40
:

This was fixed in a gist a while ago, but was never applied. I vaguely recall it was some sort of limiter that was missing on the schema-test, but do not have the exact incantation.


To reproduce:

set DBICTEST_PG_(DSN/USER/PASS)

cpanm --reinstall DBIx::Class::ResultSource::MultipleTableInheritance
cpanm --reinstall DBIx::Class::Schema::Loader


Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.Message ID: <dbsrgits/dbix-class-schema-loader/issues/37@github.com>

----==_mimepart_637a92eee526a_8c99c670570f2-- From notifications at github.com Sun Nov 20 20:49:57 2022 From: notifications at github.com (Veesh Goldman) Date: Sun, 20 Nov 2022 12:49:57 -0800 Subject: [DBIx-Class-Devel] [dbsrgits/dbix-class-schema-loader] Hook to filter the "custom content" part [rt.cpan.org #118812] (Issue #38) Message-ID: Migrated from [rt.cpan.org#118812](https://rt.cpan.org/Ticket/Display.html?id=118812) (status was 'new') Requestors: * DRAXIL at cpan.org From bogus@does.not.exist.com Sun Nov 20 20:48:46 2022 From: bogus@does.not.exist.com () Date: Sun, 20 Nov 2022 20:48:46 -0000 Subject: No subject Message-ID: ``` Hi! I have a pull request on github (https://github.com/dbsrgits/dbix-class-schema-loader/pull/11) which allows for filtering of the ungenerated part of classes, which is very useful for me and potentially other people. That's been quietly bitrotting over there for some time so I assume that doesn't get much attention so I thought I'd try my luck filing a ticket over here. Any questions or criticism please let me know. Thanks! ``` -- Reply to this email directly or view it on GitHub: https://github.com/dbsrgits/dbix-class-schema-loader/issues/38 You are receiving this because you are subscribed to this thread. Message ID: ----==_mimepart_637a92f5a57b3_562c67020906ac Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

Migrated from rt.cpan.org#118812 (status was 'new')

Requestors:

From draxil at cpan.org on 2016-11-17 15:36:15
:

Hi!

I have a pull request on github (https://github.com/dbsrgits/dbix-class-schema-loader/pull/11) which allows for filtering of the ungenerated part of classes, which is very useful for me and potentially other people. That's been quietly bitrotting over there for some time so I assume that doesn't get much attention so I thought I'd try my luck filing a ticket over here.

Any questions or criticism please let me know.

Thanks!


Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.Message ID: <dbsrgits/dbix-class-schema-loader/issues/38@github.com>

----==_mimepart_637a92f5a57b3_562c67020906ac-- From notifications at github.com Sun Nov 20 20:50:04 2022 From: notifications at github.com (Veesh Goldman) Date: Sun, 20 Nov 2022 12:50:04 -0800 Subject: [DBIx-Class-Devel] [dbsrgits/dbix-class-schema-loader] Allow us to choose the indentation (2 or 4 spaces) [rt.cpan.org #125774] (Issue #39) Message-ID: Migrated from [rt.cpan.org#125774](https://rt.cpan.org/Ticket/Display.html?id=125774) (status was 'new') Requestors: * alex.karelas at gmail.com From bogus@does.not.exist.com Sun Nov 20 20:48:46 2022 From: bogus@does.not.exist.com () Date: Sun, 20 Nov 2022 20:48:46 -0000 Subject: No subject Message-ID: ``` The classes that schema loader produces are indented with 2 spaces only. This is fine for people who code with 2 spaces, but for the rest of us who code with 4 this is a problem, as it forces us to continue coding the rest of the class (methods, etc) with 2 spaces. Because our editors like consistency. Therefore, I propose you give us the option to choose the indentation width (2 or 4 characters, or maybe even a tab character as well for the more kinky developers.) Thank you. ``` -- Reply to this email directly or view it on GitHub: https://github.com/dbsrgits/dbix-class-schema-loader/issues/39 You are receiving this because you are subscribed to this thread. Message ID: ----==_mimepart_637a92fcadf79_8493c670191628d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

Migrated from rt.cpan.org#125774 (status was 'new')

Requestors:

From alex.karelas at gmail.com on 2018-07-07 14:51:39
:

The classes that schema loader produces are indented with 2 spaces only.

This is fine for people who code with 2 spaces, but for the rest of us
who code with 4 this is a problem, as it forces us to continue coding
the rest of the class (methods, etc) with 2 spaces. Because our editors
like consistency.

Therefore, I propose you give us the option to choose the indentation
width (2 or 4 characters, or maybe even a tab character as well for the
more kinky developers.)

Thank you.


Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.Message ID: <dbsrgits/dbix-class-schema-loader/issues/39@github.com>

----==_mimepart_637a92fcadf79_8493c670191628d-- From notifications at github.com Sun Nov 20 20:50:11 2022 From: notifications at github.com (Veesh Goldman) Date: Sun, 20 Nov 2022 12:50:11 -0800 Subject: [DBIx-Class-Devel] [dbsrgits/dbix-class-schema-loader] dbicdump doesn't seem to support DBD::MariaDB [rt.cpan.org #127318] (Issue #40) Message-ID: Migrated from [rt.cpan.org#127318](https://rt.cpan.org/Ticket/Display.html?id=127318) (status was 'new') Requestors: * alex.karelas at gmail.com From bogus@does.not.exist.com Sun Nov 20 20:48:46 2022 From: bogus@does.not.exist.com () Date: Sun, 20 Nov 2022 20:48:46 -0000 Subject: No subject Message-ID: ``` I get this warning: DBIx::Class::Storage::DBI::_warn_undetermined_driver(): This version of DBIC does not yet seem to supply a driver for your particular RDBMS and/or connection method ('MariaDB'). While we will attempt to continue anyway, the results are likely to be underwhelming. Please upgrade DBIC, and if this message does not go away, file a bugreport including the following info: and then underneath, more warnings and a fatal error messages, like: DBIx::Class::Storage::DBI::sql_maker(): Your storage class (DBIx::Class::Storage::DBI) does not set sql_limit_dialect and you have not supplied an explicit limit_dialect in your connection_info. DBIC will attempt to use the GenericSubQ dialect, which works on most databases but can be (and often is) painfully slow. Please file an RT ticket against 'DBIx::Class::Storage::DBI' at /home/appuser/work/my_project/local/bin/dbicdump line 175 and Cannot find primary keys for this driver: DBIx::Class::Schema::Loader::DBI::try {...} (): DBI Exception: DBD::MariaDB::db primary_key failed: Incorrect database name '' [for Statement "SHOW KEYS FROM ``.`my_db`.`my_table`"] at /home/appuser/work/my_project/local/bin/dbicdump line 175 ``` -- Reply to this email directly or view it on GitHub: https://github.com/dbsrgits/dbix-class-schema-loader/issues/40 You are receiving this because you are subscribed to this thread. Message ID: ----==_mimepart_637a9303bea1b_1598c670186112b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

Migrated from rt.cpan.org#127318 (status was 'new')

Requestors:

From alex.karelas at gmail.com on 2018-10-09 02:18:38
:

I get this warning:

DBIx::Class::Storage::DBI::_warn_undetermined_driver(): This version of
DBIC does not yet seem to supply a driver for your particular RDBMS
and/or connection method ('MariaDB'). While we will attempt to continue
anyway, the results are likely to be underwhelming. Please upgrade DBIC,
and if this message does not go away, file a bugreport including the
following info:

and then underneath, more warnings and a fatal error messages, like:

DBIx::Class::Storage::DBI::sql_maker(): Your storage class
(DBIx::Class::Storage::DBI) does not set sql_limit_dialect and you have
not supplied an explicit limit_dialect in your connection_info. DBIC
will attempt to use the GenericSubQ dialect, which works on most
databases but can be (and often is) painfully slow. Please file an RT
ticket against 'DBIx::Class::Storage::DBI' at
/home/appuser/work/my_project/local/bin/dbicdump line 175

and

Cannot find primary keys for this driver:
DBIx::Class::Schema::Loader::DBI::try {...} (): DBI Exception:
DBD::MariaDB::db primary_key failed: Incorrect database name '' [for
Statement "SHOW KEYS FROM ``.`my_db`.`my_table`"] at
/home/appuser/work/my_project/local/bin/dbicdump line 175


Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.Message ID: <dbsrgits/dbix-class-schema-loader/issues/40@github.com>

----==_mimepart_637a9303bea1b_1598c670186112b-- From notifications at github.com Sun Nov 20 20:50:18 2022 From: notifications at github.com (Veesh Goldman) Date: Sun, 20 Nov 2022 12:50:18 -0800 Subject: [DBIx-Class-Devel] [dbsrgits/dbix-class-schema-loader] Generated classes should always use C3 mro [rt.cpan.org #132035] (Issue #41) Message-ID: Migrated from [rt.cpan.org#132035](https://rt.cpan.org/Ticket/Display.html?id=132035) (status was 'new') Requestors: * DAKKAR at cpan.org From bogus@does.not.exist.com Sun Nov 20 20:48:46 2022 From: bogus@does.not.exist.com () Date: Sun, 20 Nov 2022 20:48:46 -0000 Subject: No subject Message-ID: ``` Currently, Result classes generated by Schema::Loader use the normal Perl MRO. This creates problems when usinc a custom base class that uses multiple components, see for example https://github.com/frioux/DBIx-Class-Helpers/issues/91 and the discussion at https://github.com/frioux/DBIx-Class-Helpers/pull/103 Adding an explicit C after the C is enough to fix the problem. I'm not completely sure how C3 works in Moose classes, though. ``` -- Reply to this email directly or view it on GitHub: https://github.com/dbsrgits/dbix-class-schema-loader/issues/41 You are receiving this because you are subscribed to this thread. Message ID: ----==_mimepart_637a930a711c0_cc0c670164784e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

Migrated from rt.cpan.org#132035 (status was 'new')

Requestors:

From dakkar at cpan.org on 2020-03-01 13:09:06
:

Currently, Result classes generated by Schema::Loader use the normal Perl MRO. This creates problems when usinc a custom base class that uses multiple components, see for example https://github.com/frioux/DBIx-Class-Helpers/issues/91 and the discussion at https://github.com/frioux/DBIx-Class-Helpers/pull/103

Adding an explicit C<use mro 'c3';> after the C<use base> is enough to fix the problem. I'm not completely sure how C3 works in Moose classes, though.


Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.Message ID: <dbsrgits/dbix-class-schema-loader/issues/41@github.com>

----==_mimepart_637a930a711c0_cc0c670164784e-- From notifications at github.com Sun Nov 20 20:50:26 2022 From: notifications at github.com (Veesh Goldman) Date: Sun, 20 Nov 2022 12:50:26 -0800 Subject: [DBIx-Class-Devel] [dbsrgits/dbix-class-schema-loader] Cannot import current_timestamp() default from MariaDB [rt.cpan.org #134064] (Issue #42) Message-ID: Migrated from [rt.cpan.org#134064](https://rt.cpan.org/Ticket/Display.html?id=134064) (status was 'new') Requestors: * DLAMBLEY at cpan.org From bogus@does.not.exist.com Sun Nov 20 20:48:46 2022 From: bogus@does.not.exist.com () Date: Sun, 20 Nov 2022 20:48:46 -0000 Subject: No subject Message-ID: ``` MariaDB made a change about five years ago which causes it to say "current_timestamp()" rather than "current_timestamp". This prevent DBIx::Class::Schema::Loader from correctly importing such default values. The change happened here, https://github.com/MariaDB/server/commit/a411d7f4f670c24b43b50f7d2a1129e10218f4a7 I have made a pull request which should fix this problem, https://github.com/dbsrgits/dbix-class-schema-loader/pull/24 Best regards, Dave ``` -- Reply to this email directly or view it on GitHub: https://github.com/dbsrgits/dbix-class-schema-loader/issues/42 You are receiving this because you are subscribed to this thread. Message ID: ----==_mimepart_637a9312d0189_2a78c670555d8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

Migrated from rt.cpan.org#134064 (status was 'new')

Requestors:

From dlambley at cpan.org on 2021-01-18 18:56:27
:

MariaDB made a change about five years ago which causes it to say "current_timestamp()" rather than "current_timestamp". This prevent DBIx::Class::Schema::Loader from correctly importing such default values.

The change happened here, https://github.com/MariaDB/server/commit/a411d7f4f670c24b43b50f7d2a1129e10218f4a7

I have made a pull request which should fix this problem, https://github.com/dbsrgits/dbix-class-schema-loader/pull/24

Best regards,
Dave


Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.Message ID: <dbsrgits/dbix-class-schema-loader/issues/42@github.com>

----==_mimepart_637a9312d0189_2a78c670555d8-- From notifications at github.com Sun Nov 20 20:50:33 2022 From: notifications at github.com (Veesh Goldman) Date: Sun, 20 Nov 2022 12:50:33 -0800 Subject: [DBIx-Class-Devel] [dbsrgits/dbix-class-schema-loader] [rt.cpan.org #139826] (Issue #43) Message-ID: Migrated from [rt.cpan.org#139826](https://rt.cpan.org/Ticket/Display.html?id=139826) (status was 'new') Requestors: * ZARQUON at cpan.org From bogus@does.not.exist.com Sun Nov 20 20:48:46 2022 From: bogus@does.not.exist.com () Date: Sun, 20 Nov 2022 20:48:46 -0000 Subject: No subject Message-ID: ``` Oracle materialised views not being identified correctly. There's a partial implementation here: https://github.com/dbsrgits/dbix-class-schema-loader/pull/25 It doesn't handle the DDL creation side of things (oracle materialised views have weird scheduling syntax), and I'm not sure how to deal with test cases here, in case there's prior art I should know about. ``` -- Reply to this email directly or view it on GitHub: https://github.com/dbsrgits/dbix-class-schema-loader/issues/43 You are receiving this because you are subscribed to this thread. Message ID: ----==_mimepart_637a93196d1c2_4ca4c6701783373 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

Migrated from rt.cpan.org#139826 (status was 'new')

Requestors:

From zarquon at cpan.org on 2021-10-25 03:49:31
:

Oracle materialised views not being identified correctly.

There's a partial implementation here: https://github.com/dbsrgits/dbix-class-schema-loader/pull/25

It doesn't handle the DDL creation side of things (oracle materialised views have weird scheduling syntax), and I'm not sure how to deal with test cases here, in case there's prior art I should know about.


Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.Message ID: <dbsrgits/dbix-class-schema-loader/issues/43@github.com>

----==_mimepart_637a93196d1c2_4ca4c6701783373-- From notifications at github.com Sun Nov 20 20:50:43 2022 From: notifications at github.com (Veesh Goldman) Date: Sun, 20 Nov 2022 12:50:43 -0800 Subject: [DBIx-Class-Devel] [dbsrgits/dbix-class-schema-loader] " has no primary key" issued also for views [rt.cpan.org #25944] (Issue #44) Message-ID: Migrated from [rt.cpan.org#25944](https://rt.cpan.org/Ticket/Display.html?id=25944) (status was 'open') Requestors: * radek at pld-linux.org From bogus@does.not.exist.com Sun Nov 20 20:48:46 2022 From: bogus@does.not.exist.com () Date: Sun, 20 Nov 2022 20:48:46 -0000 Subject: No subject Message-ID: ``` I'm loading a schema which contains views. DBIx::Class::Schema::Loader::Base->_load_classess() unconditionally whines about the lack of a primary key in tables it found. For views, this is pointless, as (at least in Postgres) it's not possible to mark a column as one. ``` From bogus@does.not.exist.com Sun Nov 20 20:48:46 2022 From: bogus@does.not.exist.com () Date: Sun, 20 Nov 2022 20:48:46 -0000 Subject: No subject Message-ID: ``` I second this [old] request. It's an annoying -feature- ... perhaps a quick fix would be to 1) ignore pk definition altogether for views, or 2) look for first column of view to be named id and if so, add it is pk for ResultSource definition. Does this affect anybody else? Are there any workarounds, suggestions of a fix? I would gladly write up a patch if any comments received from the comments above... ``` From bogus@does.not.exist.com Sun Nov 20 20:48:46 2022 From: bogus@does.not.exist.com () Date: Sun, 20 Nov 2022 20:48:46 -0000 Subject: No subject Message-ID: ``` An update on this ticket: the warning is now gone. The proper fix for this is to detect views separately from tables and generate proper DBIx::Class::ResultSource::View classes with the view SQL so that they can be redeployed. Until that is done, leaving this ticket open. ``` -- Reply to this email directly or view it on GitHub: https://github.com/dbsrgits/dbix-class-schema-loader/issues/44 You are receiving this because you are subscribed to this thread. Message ID: ----==_mimepart_637a9323596ec_67c9c67018020cf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

Migrated from rt.cpan.org#25944 (status was 'open')

Requestors:

From radek at pld-linux.org on 2007-03-30 09:34:24
:

I'm loading a schema which contains views.

DBIx::Class::Schema::Loader::Base->_load_classess() unconditionally
whines about the lack of a primary key in tables it found.  For views,
this is pointless, as (at least in Postgres) it's not possible to mark
a column as one.

From aimass at cpan.org on 2009-04-12 22:47:21
:

I second this [old] request. 

It's an annoying -feature- ... perhaps a quick fix would be to 1) ignore
pk definition altogether for views, or 2) look for first column of view
to be named id and if so, add it is pk for ResultSource definition.

Does this affect anybody else? Are there any workarounds, suggestions of
a fix? I would gladly write up a patch if any comments received from the
comments above...

From rkitover at cpan.org on 2012-09-09 16:28:56
:

An update on this ticket:

the warning is now gone.

The proper fix for this is to detect views separately from tables and generate proper 
DBIx::Class::ResultSource::View classes with the view SQL so that they can be 
redeployed.

Until that is done, leaving this ticket open.


Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.Message ID: <dbsrgits/dbix-class-schema-loader/issues/44@github.com>

----==_mimepart_637a9323596ec_67c9c67018020cf-- From notifications at github.com Sun Nov 20 20:51:02 2022 From: notifications at github.com (Veesh Goldman) Date: Sun, 20 Nov 2022 12:51:02 -0800 Subject: [DBIx-Class-Devel] [dbsrgits/dbix-class-schema-loader] DBIC-Schema-Loader incompatible with Apache threads. [rt.cpan.org #38600] (Issue #45) Message-ID: Migrated from [rt.cpan.org#38600](https://rt.cpan.org/Ticket/Display.html?id=38600) (status was 'open') Requestors: * TJC at cpan.org Attachments: * [loader_bug_demo_1.tar.gz](https://rt.cpan.org/Ticket/Attachment/499208/247330/loader_bug_demo_1.tar.gz) From bogus@does.not.exist.com Sun Nov 20 20:48:46 2022 From: bogus@does.not.exist.com () Date: Sun, 20 Nov 2022 20:48:46 -0000 Subject: No subject Message-ID: ``` DBIx::Class::Loader 0.21 is not compatible with Apache running in worker(threaded) mode on Linux, at least not on my tested environment, which was: DBIx::Class::Schema::Loader 0.04005 DBIx::Class 0.08010 and 0.08099_04 DBI 1.601 (and a slightly earlier) DBD::Pg 2.8.6, 2.9.0 and another fairly older one. Note that DBIx::Class::Schema works in the same configuration when used without -Loader. I attach a fairly complete demonstration app. See README for setup/installation instructions. Also, I note that this website seems to mention the problem and a potential couple of fixes: http://d.hatena.ne.jp/holidays-l/20070126/p1 Unfortunately I can't read Japanese, but the code itself looks OK. ``` From bogus@does.not.exist.com Sun Nov 20 20:48:46 2022 From: bogus@does.not.exist.com () Date: Sun, 20 Nov 2022 20:48:46 -0000 Subject: No subject Message-ID: ``` Note that I've just tested against the current latest dev release, and the problem remains. ``` From bogus@does.not.exist.com Sun Nov 20 20:48:46 2022 From: bogus@does.not.exist.com () Date: Sun, 20 Nov 2022 20:48:46 -0000 Subject: No subject Message-ID: ``` On Wed Aug 20 02:35:50 2008, TJC wrote: > DBIx::Class::Loader 0.21 is not compatible with Apache running in > worker(threaded) mode on Linux, at least not on my tested environment, > which was: > DBIx::Class::Schema::Loader 0.04005 > DBIx::Class 0.08010 and 0.08099_04 > DBI 1.601 (and a slightly earlier) > DBD::Pg 2.8.6, 2.9.0 and another fairly older one. > > Note that DBIx::Class::Schema works in the same configuration when used > without -Loader. > > I attach a fairly complete demonstration app. See README for > setup/installation instructions. > > > Also, I note that this website seems to mention the problem and a > potential couple of fixes: http://d.hatena.ne.jp/holidays-l/20070126/p1 > Unfortunately I can't read Japanese, but the code itself looks OK. Is this still a problem? ``` From bogus@does.not.exist.com Sun Nov 20 20:48:46 2022 From: bogus@does.not.exist.com () Date: Sun, 20 Nov 2022 20:48:46 -0000 Subject: No subject Message-ID: ``` On Thu Dec 02 07:38:28 2010, RIBASUSHI wrote: > On Wed Aug 20 02:35:50 2008, TJC wrote: > > DBIx::Class::Loader 0.21 is not compatible with Apache running in > > worker(threaded) mode on Linux, at least not on my tested environment, > > which was: > > DBIx::Class::Schema::Loader 0.04005 > > DBIx::Class 0.08010 and 0.08099_04 > > DBI 1.601 (and a slightly earlier) > > DBD::Pg 2.8.6, 2.9.0 and another fairly older one. > > > > Note that DBIx::Class::Schema works in the same configuration when used > > without -Loader. > > > > I attach a fairly complete demonstration app. See README for > > setup/installation instructions. > > > > > > Also, I note that this website seems to mention the problem and a > > potential couple of fixes: http://d.hatena.ne.jp/holidays-l/20070126/p1 > > Unfortunately I can't read Japanese, but the code itself looks OK. > > Is this still a problem? Took me a while to build a new VM and set it up with everything, since I don't run Apache any more, especially not the threaded version. However - yes, I can confirm the problem still occurs on Ubuntu Maverick, with its versions of Apache (2.2), Perl (5.10.1), mod_perl, mpm_worker, and all the latest version of Perl modules installed from CPAN. http://192.168.1.204/testdbic/loader Caught exception in MyApp::Controller::Root->loader "DBD::Pg::db STORE failed: handle 2 is owned by thread 7f0ffc427bf0 not current thread 7f1002cd92c0 (handles can't be shared between threads and your driver may need a CLONE method added) at /usr/local/share/perl/5.10.1/DBIx/Class/Storage/DBI.pm line 217." ``` From bogus@does.not.exist.com Sun Nov 20 20:48:46 2022 From: bogus@does.not.exist.com () Date: Sun, 20 Nov 2022 20:48:46 -0000 Subject: No subject Message-ID: ``` BTW I opened another ticket (63558) about some warnings in the unit tests from DBIC about DCSL holding cached references when it shouldn't be.. I just wondered if maybe that's related to this bug, since if DCSL was closing the handles properly then the new threads would all re-open their own handles just fine. Or maybe it's unrelated. ``` -- Reply to this email directly or view it on GitHub: https://github.com/dbsrgits/dbix-class-schema-loader/issues/45 You are receiving this because you are subscribed to this thread. Message ID: ----==_mimepart_637a93362dc92_71f2c6701899635 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

Migrated from rt.cpan.org#38600 (status was 'open')

Requestors:

Attachments:

From tjc at cpan.org on 2008-08-20 06:35:50
:

DBIx::Class::Loader 0.21 is not compatible with Apache running in
worker(threaded) mode on Linux, at least not on my tested environment,
which was:
DBIx::Class::Schema::Loader 0.04005
DBIx::Class 0.08010 and 0.08099_04
DBI 1.601 (and a slightly earlier)
DBD::Pg 2.8.6, 2.9.0 and another fairly older one.

Note that DBIx::Class::Schema works in the same configuration when used
without -Loader.

I attach a fairly complete demonstration app. See README for
setup/installation instructions.


Also, I note that this website seems to mention the problem and a
potential couple of fixes: http://d.hatena.ne.jp/holidays-l/20070126/p1
Unfortunately I can't read Japanese, but the code itself looks OK.

From tjc at cpan.org on 2008-08-20 06:43:37
:

Note that I've just tested against the current latest dev release, and
the problem remains.

From ribasushi at leporine.io on 2010-12-02 12:38:28
:

On Wed Aug 20 02:35:50 2008, TJC wrote:
> DBIx::Class::Loader 0.21 is not compatible with Apache running in
> worker(threaded) mode on Linux, at least not on my tested environment,
> which was:
> DBIx::Class::Schema::Loader 0.04005
> DBIx::Class 0.08010 and 0.08099_04
> DBI 1.601 (and a slightly earlier)
> DBD::Pg 2.8.6, 2.9.0 and another fairly older one.
> 
> Note that DBIx::Class::Schema works in the same configuration when used
> without -Loader.
> 
> I attach a fairly complete demonstration app. See README for
> setup/installation instructions.
> 
> 
> Also, I note that this website seems to mention the problem and a
> potential couple of fixes: http://d.hatena.ne.jp/holidays-l/20070126/p1
> Unfortunately I can't read Japanese, but the code itself looks OK.

Is this still a problem?

From tjc at cpan.org on 2010-12-03 02:34:43
:

On Thu Dec 02 07:38:28 2010, RIBASUSHI wrote:
> On Wed Aug 20 02:35:50 2008, TJC wrote:
> > DBIx::Class::Loader 0.21 is not compatible with Apache running in
> > worker(threaded) mode on Linux, at least not on my tested environment,
> > which was:
> > DBIx::Class::Schema::Loader 0.04005
> > DBIx::Class 0.08010 and 0.08099_04
> > DBI 1.601 (and a slightly earlier)
> > DBD::Pg 2.8.6, 2.9.0 and another fairly older one.
> > 
> > Note that DBIx::Class::Schema works in the same configuration when used
> > without -Loader.
> > 
> > I attach a fairly complete demonstration app. See README for
> > setup/installation instructions.
> > 
> > 
> > Also, I note that this website seems to mention the problem and a
> > potential couple of fixes: http://d.hatena.ne.jp/holidays-l/20070126/p1
> > Unfortunately I can't read Japanese, but the code itself looks OK.
> 
> Is this still a problem?

Took me a while to build a new VM and set it up with everything, since I don't run 
Apache any more, especially not the threaded version.

However - yes, I can confirm the problem still occurs on Ubuntu Maverick, with its 
versions of Apache (2.2), Perl (5.10.1), mod_perl, mpm_worker, and all the latest 
version of Perl modules installed from CPAN.


http://192.168.1.204/testdbic/loader

Caught exception in MyApp::Controller::Root->loader "DBD::Pg::db STORE failed: 
handle 2 is owned by thread 7f0ffc427bf0 not current thread 7f1002cd92c0 (handles 
can't be shared between threads and your driver may need a CLONE method added) at 
/usr/local/share/perl/5.10.1/DBIx/Class/Storage/DBI.pm line 217."

From tjc at cpan.org on 2010-12-03 02:39:20
:

BTW I opened another ticket (63558) about some warnings in the unit tests 
from DBIC about DCSL holding cached references when it shouldn't be..
I just wondered if maybe that's related to this bug, since if DCSL was 
closing the handles properly then the new threads would all re-open their 
own handles just fine.

Or maybe it's unrelated.


Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.Message ID: <dbsrgits/dbix-class-schema-loader/issues/45@github.com>

----==_mimepart_637a93362dc92_71f2c6701899635-- From notifications at github.com Sun Nov 20 20:51:14 2022 From: notifications at github.com (Veesh Goldman) Date: Sun, 20 Nov 2022 12:51:14 -0800 Subject: [DBIx-Class-Devel] [dbsrgits/dbix-class-schema-loader] need POD table and column comments for more backends [rt.cpan.org #53855] (Issue #46) Message-ID: Migrated from [rt.cpan.org#53855](https://rt.cpan.org/Ticket/Display.html?id=53855) (status was 'open') Requestors: * rmb32 at cornell.edu From bogus@does.not.exist.com Sun Nov 20 20:48:46 2022 From: bogus@does.not.exist.com () Date: Sun, 20 Nov 2022 20:48:46 -0000 Subject: No subject Message-ID: ``` Need implementations of _table_comment and _column_comment for more backends (oracle, db2, mssql...) With extra tests covering them of course. ``` From bogus@does.not.exist.com Sun Nov 20 20:48:46 2022 From: bogus@does.not.exist.com () Date: Sun, 20 Nov 2022 20:48:46 -0000 Subject: No subject Message-ID: ``` Oracle support added: http://git.shadowcat.co.uk/gitweb/gitweb.cgi? p=dbsrgits/DBIx-Class-Schema- Loader.git;a=commitdiff;h=4cd5155bb0df2e2e59378d9e878af90285967e12 On Wed Jan 20 14:50:17 2010, rbuels wrote: > Need implementations of _table_comment and _column_comment for more > backends (oracle, db2, mssql...) > > With extra tests covering them of course. > ``` From bogus@does.not.exist.com Sun Nov 20 20:48:46 2022 From: bogus@does.not.exist.com () Date: Sun, 20 Nov 2022 20:48:46 -0000 Subject: No subject Message-ID: ``` An update on this ticket: SineSwiper added support for the REMARKS field from $dbh->table_info and $dbh- >column_info in _table_comment and _column_comment in ::DBI. Someone else (I forget who) added better support for MySQL, even though MySQL's support for comments is very lacking. There is also a generic mechanism available to store your comments in tables, a table_comments and column_comments tables (overridable via table_comments_table and column_comments_table attributes.) What is left is to investigate and test comment support for other supported DBs. ``` From bogus@does.not.exist.com Sun Nov 20 20:48:46 2022 From: bogus@does.not.exist.com () Date: Sun, 20 Nov 2022 20:48:46 -0000 Subject: No subject Message-ID: ``` for MSSQL: select t.name [Table], prop.value [TableComment] from sys.tables t left join sys.extended_properties prop on t.object_id = prop.major_id and prop.minor_id = 0 and prop.name = 'MS_Description' select t.name [Table], c.name [Column], prop.value [ColumnComment] from sys.tables t inner join sys.columns c on t.object_id = c.object_id left join sys.extended_properties prop on t.object_id = prop.major_id and c.column_id = prop.minor_id and prop.name = 'MS_Description' ``` -- Reply to this email directly or view it on GitHub: https://github.com/dbsrgits/dbix-class-schema-loader/issues/46 You are receiving this because you are subscribed to this thread. Message ID: ----==_mimepart_637a934282215_3027c67021618e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

Migrated from rt.cpan.org#53855 (status was 'open')

Requestors:

From rmb32 at cornell.edu on 2010-01-20 19:50:17
:

Need implementations of _table_comment and _column_comment for more
backends (oracle, db2, mssql...)

With extra tests covering them of course.

From justin.d.hunter at gmail.com on 2010-10-30 04:22:24
:

Oracle support added: http://git.shadowcat.co.uk/gitweb/gitweb.cgi?
p=dbsrgits/DBIx-Class-Schema-
Loader.git;a=commitdiff;h=4cd5155bb0df2e2e59378d9e878af90285967e12

On Wed Jan 20 14:50:17 2010, rbuels wrote:
> Need implementations of _table_comment and _column_comment for more
> backends (oracle, db2, mssql...)
> 
> With extra tests covering them of course.
> 


From rkitover at cpan.org on 2012-09-09 16:26:32
:

An update on this ticket:

SineSwiper added support for the REMARKS field from $dbh->table_info and $dbh-
>column_info in _table_comment and _column_comment in ::DBI.

Someone else (I forget who) added better support for MySQL, even though MySQL's 
support for comments is very lacking.

There is also a generic mechanism available to store your comments in tables, a 
table_comments and column_comments tables (overridable via table_comments_table 
and column_comments_table attributes.)

What is left is to investigate and test comment support for other supported DBs.

From daxim at cpan.org on 2017-06-22 14:44:47
:

for MSSQL:

select t.name [Table], prop.value [TableComment]
from sys.tables t left join sys.extended_properties prop
on t.object_id = prop.major_id and prop.minor_id = 0 and prop.name = 'MS_Description'

select t.name [Table], c.name [Column], prop.value [ColumnComment]
from sys.tables t
inner join sys.columns c on t.object_id = c.object_id
left join sys.extended_properties prop
on t.object_id = prop.major_id and c.column_id = prop.minor_id and prop.name = 'MS_Description'


Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.Message ID: <dbsrgits/dbix-class-schema-loader/issues/46@github.com>

----==_mimepart_637a934282215_3027c67021618e-- From notifications at github.com Sun Nov 20 20:51:27 2022 From: notifications at github.com (Veesh Goldman) Date: Sun, 20 Nov 2022 12:51:27 -0800 Subject: [DBIx-Class-Devel] [dbsrgits/dbix-class-schema-loader] Version 0.06+ and size info for integers and various other columns [rt.cpan.org #59640] (Issue #47) Message-ID: Migrated from [rt.cpan.org#59640](https://rt.cpan.org/Ticket/Display.html?id=59640) (status was 'open') Requestors: * maz at mlx.net From bogus@does.not.exist.com Sun Nov 20 20:48:46 2022 From: bogus@does.not.exist.com () Date: Sun, 20 Nov 2022 20:48:46 -0000 Subject: No subject Message-ID: ``` 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 ``` From bogus@does.not.exist.com Sun Nov 20 20:48:46 2022 From: bogus@does.not.exist.com () Date: Sun, 20 Nov 2022 20:48:46 -0000 Subject: No subject Message-ID: ``` 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: > 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 > > ``` From bogus@does.not.exist.com Sun Nov 20 20:48:46 2022 From: bogus@does.not.exist.com () Date: Sun, 20 Nov 2022 20:48:46 -0000 Subject: No subject Message-ID: ``` 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? ``` From bogus@does.not.exist.com Sun Nov 20 20:48:46 2022 From: bogus@does.not.exist.com () Date: Sun, 20 Nov 2022 20:48:46 -0000 Subject: No subject Message-ID: ``` 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: > > > 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? ``` -- Reply to this email directly or view it on GitHub: https://github.com/dbsrgits/dbix-class-schema-loader/issues/47 You are receiving this because you are subscribed to this thread. Message ID: ----==_mimepart_637a934f5469c_752fc67019295b9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

Migrated from rt.cpan.org#59640 (status was 'open')

Requestors:

From maz at mlx.net on 2010-07-23 06:38:09
:

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

From rkitover at cpan.org on 2010-07-27 21:36:50
:

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:
> 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
> 
> 

From rkitover at cpan.org on 2011-01-21 04:19:13
:

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?

From maz at mlx.net on 2011-01-21 05:42:59
:

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:
> <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?


Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.Message ID: <dbsrgits/dbix-class-schema-loader/issues/47@github.com>

----==_mimepart_637a934f5469c_752fc67019295b9-- From notifications at github.com Sun Nov 20 20:51:36 2022 From: notifications at github.com (Veesh Goldman) Date: Sun, 20 Nov 2022 12:51:36 -0800 Subject: [DBIx-Class-Devel] [dbsrgits/dbix-class-schema-loader] Text fields cannot be indexed without truncation in mysql [rt.cpan.org #68734] (Issue #48) Message-ID: Migrated from [rt.cpan.org#68734](https://rt.cpan.org/Ticket/Display.html?id=68734) (status was 'open') Requestors: * michael.du-pont at dress-for-less.de From bogus@does.not.exist.com Sun Nov 20 20:48:46 2022 From: bogus@does.not.exist.com () Date: Sun, 20 Nov 2022 20:48:46 -0000 Subject: No subject Message-ID: ``` This table cannot be round tripped via the CREATE TABLE GOOD ( sometext text NOT NULL, UNIQUE KEY sometext2 ( sometext(150)) ) dbicdump -o dump_directory=./lib -o components='["InflateColumn::DateTime"]' DFL::Schema::TEST "dbi:mysql:database=$1:host=dbslave2" UID PWD '{ overwrite_modifications => 1, quote_char => "`" }' Produces : __PACKAGE__->add_unique_constraint("sometext2", [ "sometext"]); This produces bad sql when deployed: my $schema = Test::Schema::TEST->connect("dbi:mysql:dbname=${db}", $user, $pass); $schema->create_ddl_dir(['MySQL', 'SQLite', 'PostgreSQL'], '0.1', './sql/' ); $schema->deploy({ add_drop_table => 1}); ############ CREATE TABLE BAD ( sometext text NOT NULL, UNIQUE KEY sometext2 ( sometext) ) ``` From bogus@does.not.exist.com Sun Nov 20 20:48:46 2022 From: bogus@does.not.exist.com () Date: Sun, 20 Nov 2022 20:48:46 -0000 Subject: No subject Message-ID: ``` Adding dependency on the sqlt support ticket - without having an sqlt infrastructure to consume index lengths, there's no point of adding this to dbic. ``` -- Reply to this email directly or view it on GitHub: https://github.com/dbsrgits/dbix-class-schema-loader/issues/48 You are receiving this because you are subscribed to this thread. Message ID: ----==_mimepart_637a935845658_7f91c67018864b7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

Migrated from rt.cpan.org#68734 (status was 'open')

Requestors:

From michael.du-pont at dress-for-less.de on 2011-06-10 10:12:31
:

This table cannot be round tripped via the 

CREATE TABLE GOOD (
  sometext text NOT NULL,
  UNIQUE KEY sometext2 ( sometext(150))
) 

dbicdump -o dump_directory=./lib  -o
components='["InflateColumn::DateTime"]' DFL::Schema::TEST
"dbi:mysql:database=$1:host=dbslave2" UID PWD '{ overwrite_modifications
=> 1, quote_char => "`" }'

Produces :

__PACKAGE__->add_unique_constraint("sometext2", [ "sometext"]);

This produces bad sql when deployed:


my $schema = Test::Schema::TEST->connect("dbi:mysql:dbname=${db}",
$user, $pass);
    $schema->create_ddl_dir(['MySQL', 'SQLite', 'PostgreSQL'],
			    '0.1',
			    './sql/'
	);

    $schema->deploy({ add_drop_table => 1});

############

CREATE TABLE BAD (
  sometext text NOT NULL,
  UNIQUE KEY sometext2 ( sometext)
) 

From ribasushi at leporine.io on 2011-06-10 10:23:23
:

Adding dependency on the sqlt support ticket - without having an sqlt
infrastructure to consume index lengths, there's no point of adding this
to dbic.


Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.Message ID: <dbsrgits/dbix-class-schema-loader/issues/48@github.com>

----==_mimepart_637a935845658_7f91c67018864b7-- From notifications at github.com Sun Nov 20 20:51:48 2022 From: notifications at github.com (Veesh Goldman) Date: Sun, 20 Nov 2022 12:51:48 -0800 Subject: [DBIx-Class-Devel] [dbsrgits/dbix-class-schema-loader] Optionally warn when a relationship is redefined [PATCH] [rt.cpan.org #73876] (Issue #49) Message-ID: Migrated from [rt.cpan.org#73876](https://rt.cpan.org/Ticket/Display.html?id=73876) (status was 'open') Requestors: * TIMB at cpan.org Attachments: * [dbix-class-rel-redef-warn.patch](https://rt.cpan.org/Ticket/Attachment/1020517/532214/dbix-class-rel-redef-warn.patch) From bogus@does.not.exist.com Sun Nov 20 20:48:46 2022 From: bogus@does.not.exist.com () Date: Sun, 20 Nov 2022 20:48:46 -0000 Subject: No subject Message-ID: ``` We've been using Schema::Loader for years on a large postgresql database. Over the years we've had to add manual relationships to the generated schema files because S:L was missing them for various reasons (often because they weren't declared in the database itself yet). Now our schema is more complete and S:L is better at finding relationships and is adding them to the generated schema files. However, they're being silently overridden by the manual relationships we added previously. The old manually added relationships are usually incomplete and sometimes plain wrong. The attached patch makes it easy to identify redefined relationships. It carps is a relationship is redefined while DBIC_TRACE is set. Some other env var or control mechanism could be used, I just picked DBIC_TRACE as an easy option. (I'd be happy if warnings were the default and were silenced by adding an attribute like is_redefintion=>1 to the new relationship definition.) ``` From bogus@does.not.exist.com Sun Nov 20 20:48:46 2022 From: bogus@does.not.exist.com () Date: Sun, 20 Nov 2022 20:48:46 -0000 Subject: No subject Message-ID: ``` Committed to topic/rel_redef_warn ``` From bogus@does.not.exist.com Sun Nov 20 20:48:46 2022 From: bogus@does.not.exist.com () Date: Sun, 20 Nov 2022 20:48:46 -0000 Subject: No subject Message-ID: ``` On Tue, Jan 10, 2012 at 07:46:36AM -0500, Tim_Bunce via RT wrote: > Tue Jan 10 07:46:34 2012: Request 73876 was acted upon. > Transaction: Ticket created by TIMB > Queue: DBIx-Class > Subject: Optionally warn when a relationship is redefined [PATCH] > Broken in: (no value) > Severity: Unimportant > Owner: Nobody > Requestors: TIMB at cpan.org > Status: new > Ticket > > > We've been using Schema::Loader for years on a large postgresql database. Over the years > we've had to add manual relationships to the generated schema files because S:L was missing > them for various reasons (often because they weren't declared in the database itself yet). > > Now our schema is more complete and S:L is better at finding relationships and is adding > them to the generated schema files. However, they're being silently overridden by the manual > relationships we added previously. The old manually added relationships are usually > incomplete and sometimes plain wrong. > Newer versions of S::L are detecting such cases and issue the corresponding warnings. If your S::L is upgraded, and you are not seeing those - this is a bug in S::L itself. The other consideration to take is that silent overrides can happen on column accessors, in adition to relationship accessors. S::L is supposed to detect this as well (also it should detect static compile-time sub{}s). As far as the patch is concerned - I am really wary of tying warn-toggle semantics into DBIC_TRACE itself. I will be back on IRC next Monday, we can discuss options then. Cheers ``` -- Reply to this email directly or view it on GitHub: https://github.com/dbsrgits/dbix-class-schema-loader/issues/49 You are receiving this because you are subscribed to this thread. Message ID: ----==_mimepart_637a9364f016b_9013c67023282cd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

Migrated from rt.cpan.org#73876 (status was 'open')

Requestors:

Attachments:

From timb at cpan.org on 2012-01-10 12:46:34
:

We've been using Schema::Loader for years on a large postgresql database. Over the years 
we've had to add manual relationships to the generated schema files because S:L was missing 
them for various reasons (often because they weren't declared in the database itself yet).

Now our schema is more complete and S:L is better at finding relationships and is adding 
them to the generated schema files. However, they're being silently overridden by the manual 
relationships we added previously.  The old manually added relationships are usually 
incomplete and sometimes plain wrong.

The attached patch makes it easy to identify redefined relationships. It carps is a relationship 
is redefined while DBIC_TRACE is set.

Some other env var or control mechanism could be used, I just picked DBIC_TRACE as an easy 
option. (I'd be happy if warnings were the default and were silenced by adding an attribute 
like is_redefintion=>1 to the new relationship definition.)

From rkitover at cpan.org on 2012-01-10 13:03:54
:

Committed to topic/rel_redef_warn

From ribasushi at leporine.io on 2012-01-11 08:41:44
:

On Tue, Jan 10, 2012 at 07:46:36AM -0500, Tim_Bunce via RT wrote:
> Tue Jan 10 07:46:34 2012: Request 73876 was acted upon.
> Transaction: Ticket created by TIMB
>        Queue: DBIx-Class
>      Subject: Optionally warn when a relationship is redefined [PATCH]
>    Broken in: (no value)
>     Severity: Unimportant
>        Owner: Nobody
>   Requestors: TIMB at cpan.org
>       Status: new
>  Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=73876 >
> 
> 
> We've been using Schema::Loader for years on a large postgresql database. Over the years 
> we've had to add manual relationships to the generated schema files because S:L was missing 
> them for various reasons (often because they weren't declared in the database itself yet).
> 
> Now our schema is more complete and S:L is better at finding relationships and is adding 
> them to the generated schema files. However, they're being silently overridden by the manual 
> relationships we added previously.  The old manually added relationships are usually 
> incomplete and sometimes plain wrong.
> 

Newer versions of S::L are detecting such cases and issue the corresponding warnings.
If your S::L is upgraded, and you are not seeing those - this is a bug in S::L itself.

The other consideration to take is that silent overrides can happen on column accessors,
in adition to relationship accessors. S::L is supposed to detect this as well (also
it should detect static compile-time sub{}s).

As far as the patch is concerned - I am really wary of tying warn-toggle semantics
into DBIC_TRACE itself. I will be back on IRC next Monday, we can discuss options
then.

Cheers


Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.Message ID: <dbsrgits/dbix-class-schema-loader/issues/49@github.com>

----==_mimepart_637a9364f016b_9013c67023282cd-- From notifications at github.com Sun Nov 20 20:51:59 2022 From: notifications at github.com (Veesh Goldman) Date: Sun, 20 Nov 2022 12:51:59 -0800 Subject: [DBIx-Class-Devel] [dbsrgits/dbix-class-schema-loader] lack of accessors name sanity checking is breaking existing code [rt.cpan.org #81112] (Issue #50) Message-ID: Migrated from [rt.cpan.org#81112](https://rt.cpan.org/Ticket/Display.html?id=81112) (status was 'open') Requestors: * CMCKAY at cpan.org From bogus@does.not.exist.com Sun Nov 20 20:48:46 2022 From: bogus@does.not.exist.com () Date: Sun, 20 Nov 2022 20:48:46 -0000 Subject: No subject Message-ID: ``` Hi, Upgraded Class::Accessor::Grouped and some of my existing code stopped working. The code in question is a dbix::class schema generated by DBIx::Class::Schema::Loader and used one of my db column names (1900_call_description) as an accessor name. Can you revert the sanity checking so accessors can start with a digit again please. Thanks, -Chris Mckay ``` From bogus@does.not.exist.com Sun Nov 20 20:48:46 2022 From: bogus@does.not.exist.com () Date: Sun, 20 Nov 2022 20:48:46 -0000 Subject: No subject Message-ID: ``` I switched the queue of this bug, as it is S::L's problem, not CAG's. You are confusing the ability to have columns with any name, with the ability to create an arbitrary accessor name. You may not do the later in perl (at least not normally) - every accessor must* conform to /\A[A-Z_a-z][0-9A-Z_a-z]*\z/. This is not only limited to numbers - S::L has a general deficiency in constructiong accessor names. It has been argued for several years that S::L must sanitycheck all resulting accessor names and specify 'accessor => undef' for anything that seems out of line. Sadly the former maintainer was extremely uncooperative on this problem. So two courses of action: Long term _default_column_accessor_name() needs a facelift to stop asking the system to create accessors with illegal names (patches very very very welcome). Short term all you need to do is provide a custom column naming callback via https://metacpan.org/module/DBIx::Class::Schema::Loader::Base#col_accessor_map In the meantime I will have to re-relase a CAG with the ability to shutoff the check via an envvar. Creating broken accessor names however will not be the default mode of operation. Cheers * The "must" here is a little ambiguous. One of course can always do $obj->${\"666 random crap of a name"}, but one can never do 'sub 666_haha { ... }'. Since the job of CAG is to make generally accessible accessors (haha), there is little argument in allowing weird naming. Especially given the workaround availability as stated above. ``` From bogus@does.not.exist.com Sun Nov 20 20:48:46 2022 From: bogus@does.not.exist.com () Date: Sun, 20 Nov 2022 20:48:46 -0000 Subject: No subject Message-ID: ``` On Sun Nov 11 23:54:27 2012, CMCKAY wrote: > Can you revert the sanity checking so accessors can start with a digit > again please. Class::Accessor::Grouped with a builtin escape hatch uploaded to CPAN. Sorry for the delay. Rationale can be found here[1]. The bug is still valid and critical - DBIC::SL must stop attempting to create bogus accessors. [1] https://metacpan.org/module/RIBASUSHI/Class-Accessor-Grouped-0.10008/lib/Class/Accessor/Grouped.pm#Notes-on-accessor-names ``` -- Reply to this email directly or view it on GitHub: https://github.com/dbsrgits/dbix-class-schema-loader/issues/50 You are receiving this because you are subscribed to this thread. Message ID: ----==_mimepart_637a936fb1cad_5124c6701760088 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

Migrated from rt.cpan.org#81112 (status was 'open')

Requestors:

From cmckay at cpan.org on 2012-11-12 04:54:27
:

Hi,

Upgraded Class::Accessor::Grouped and some of my existing code stopped 
working. The code in question is a dbix::class schema generated by 
DBIx::Class::Schema::Loader and used one of my db column names 
(1900_call_description) as an accessor name. Can you revert the sanity 
checking so accessors can start with a digit again please.


Thanks,
-Chris Mckay

From ribasushi at leporine.io on 2012-11-12 09:22:15
:

I switched the queue of this bug, as it is S::L's problem, not CAG's.
You are confusing the ability to have columns with any name, with the
ability to create an arbitrary accessor name. You may not do the later
in perl (at least not normally) - every accessor must* conform to
/\A[A-Z_a-z][0-9A-Z_a-z]*\z/.

This is not only limited to numbers - S::L has a general deficiency in
constructiong accessor names. It has been argued for several years that
S::L must sanitycheck all resulting accessor names and specify 'accessor
=> undef' for anything that seems out of line. Sadly the former
maintainer was extremely uncooperative on this problem.

So two courses of action:
Long term  _default_column_accessor_name() needs a facelift to stop
asking the system to create accessors with illegal names (patches very
very very welcome).
Short term all you need to do is provide a custom column naming callback
via
https://metacpan.org/module/DBIx::Class::Schema::Loader::Base#col_accessor_map

In the meantime I will have to re-relase a CAG with the ability to
shutoff the check via an envvar. Creating broken accessor names however
will not be the default mode of operation.

Cheers

* The "must" here is a little ambiguous. One of course can always do
$obj->${\"666 random crap of a name"}, but one can never do 'sub
666_haha { ... }'. Since the job of CAG is to make generally accessible
accessors (haha), there is little argument in allowing weird naming.
Especially given the workaround availability as stated above.

From ribasushi at leporine.io on 2012-11-15 10:10:55
:

On Sun Nov 11 23:54:27 2012, CMCKAY wrote:
> Can you revert the sanity checking so accessors can start with a digit
> again please.

Class::Accessor::Grouped with a builtin escape hatch uploaded to CPAN.
Sorry for the delay. Rationale can be found here[1].

The bug is still valid and critical - DBIC::SL must stop attempting to
create bogus accessors.

[1]
https://metacpan.org/module/RIBASUSHI/Class-Accessor-Grouped-0.10008/lib/Class/Accessor/Grouped.pm#Notes-on-accessor-names


Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.Message ID: <dbsrgits/dbix-class-schema-loader/issues/50@github.com>

----==_mimepart_637a936fb1cad_5124c6701760088-- From notifications at github.com Sun Nov 20 20:52:13 2022 From: notifications at github.com (Veesh Goldman) Date: Sun, 20 Nov 2022 12:52:13 -0800 Subject: [DBIx-Class-Devel] [dbsrgits/dbix-class-schema-loader] MySQL view_definition contains db name [rt.cpan.org #119996] (Issue #51) Message-ID: Migrated from [rt.cpan.org#119996](https://rt.cpan.org/Ticket/Display.html?id=119996) (status was 'open') Requestors: * pushtaev at cpan.org From bogus@does.not.exist.com Sun Nov 20 20:48:46 2022 From: bogus@does.not.exist.com () Date: Sun, 20 Nov 2022 20:48:46 -0000 Subject: No subject Message-ID: ``` Hi! Since the last update, DBIx::Class::Schema::Loader automatically creates `view_definition` for views. In case of MySQL it uses `SELECT view_definition FROM information_schema.views ...` query and the result of this query contains the database name along with every table name: `project`.`user` instead of just `user`. It's a big issue for our project since different users and environments use different database names. It would be great to have view definition without database name or at least disable view_definition generation at all. Thank you! ``` From bogus@does.not.exist.com Sun Nov 20 20:48:46 2022 From: bogus@does.not.exist.com () Date: Sun, 20 Nov 2022 20:48:46 -0000 Subject: No subject Message-ID: ``` Hi Vadim, "Pushtaev Vadim via RT" writes: > Hi! > > Since the last update, DBIx::Class::Schema::Loader automatically > creates `view_definition` for views. In case of MySQL it uses `SELECT > view_definition FROM information_schema.views ...` query and the > result of this query contains the database name along with every table > name: `project`.`user` instead of just `user`. Schema::Loader does deliberately not do anything with the view definition SQL, since that would require a fully-fledged SQL parser. This is incidentally why it does not introspect the view definition for DB2, since that only gives you the whole CREATE VIEW statement, not the body separately. > It's a big issue for our project since different users and > environments use different database names. It would be great to have > view definition without database name or at least disable > view_definition generation at all. For non-virtual views, the view definition is only used for ->deploy. The fact that you're happy with not having it generated at all makes it seem to me that you're not using deploy, so the definition is purely informative. If you really need it, you can add an sqlt_deploy_hook method to the result class that modifies $view->sql as appropriate for your specific case. Hope this helps, 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 ``` From bogus@does.not.exist.com Sun Nov 20 20:48:46 2022 From: bogus@does.not.exist.com () Date: Sun, 20 Nov 2022 20:48:46 -0000 Subject: No subject Message-ID: ``` We do use `deploy` indeed. Previously we just added view_definition manually, but we would be happy to use auto-generated one (we have already monkey-patched Schema::Loader not to generate view_definiton as a workaround). I understand you don't want to parse SQL, but there is a way to get view definition from MySQL without database name: https://dev.mysql.com/doc/refman/5.7/en/show-create-view.html On Thu Jan 26 13:27:15 2017, ilmari at ilmari.org wrote: > Hi Vadim, > > "Pushtaev Vadim via RT" > writes: > > > Hi! > > > > Since the last update, DBIx::Class::Schema::Loader automatically > > creates `view_definition` for views. In case of MySQL it uses `SELECT > > view_definition FROM information_schema.views ...` query and the > > result of this query contains the database name along with every table > > name: `project`.`user` instead of just `user`. > > Schema::Loader does deliberately not do anything with the view > definition SQL, since that would require a fully-fledged SQL parser. > This is incidentally why it does not introspect the view definition for > DB2, since that only gives you the whole CREATE VIEW statement, not the > body separately. > > > It's a big issue for our project since different users and > > environments use different database names. It would be great to have > > view definition without database name or at least disable > > view_definition generation at all. > > For non-virtual views, the view definition is only used for ->deploy. > The fact that you're happy with not having it generated at all makes it > seem to me that you're not using deploy, so the definition is purely > informative. > > If you really need it, you can add an sqlt_deploy_hook method to the > result class that modifies $view->sql as appropriate for your specific > case. > > Hope this helps, > > Ilmari > ``` From bogus@does.not.exist.com Sun Nov 20 20:48:46 2022 From: bogus@does.not.exist.com () Date: Sun, 20 Nov 2022 20:48:46 -0000 Subject: No subject Message-ID: ``` "Pushtaev Vadim via RT" writes: > We do use `deploy` indeed. Previously we just added view_definition > manually, but we would be happy to use auto-generated one (we have > already monkey-patched Schema::Loader not to generate view_definiton > as a workaround). > I understand you don't want to parse SQL, but there is a way to get > view definition from MySQL without database name: > https://dev.mysql.com/doc/refman/5.7/en/show-create-view.html That has the same problem as DB2: It includes the whole CREATE VIEW statement, not just the query. Also, whether it includes the database name (which is really the schema, in standard SQL parlance) depends on whether your current schema matches the one of the (tables used) in the view. mysql> \r test mysql> show create view test.bar \G *************************** 1. row *************************** View: bar Create View: CREATE ALGORITHM=UNDEFINED DEFINER=`ilmari`@`%` SQL SECURITY DEFINER VIEW `bar` AS select `foo`.`id` AS `id` from `foo` character_set_client: utf8 collation_connection: utf8_general_ci 1 row in set (0.00 sec) mysql> \r dbictest mysql> show create view test.bar \G *************************** 1. row *************************** View: bar Create View: CREATE ALGORITHM=UNDEFINED DEFINER=`ilmari`@`%` SQL SECURITY DEFINER VIEW `test`.`bar` AS select `test`.`foo`.`id` AS `id` from `test`.`foo` character_set_client: utf8 collation_connection: utf8_general_ci 1 row in set (0.00 sec) > On Thu Jan 26 13:27:15 2017, ilmari at ilmari.org wrote: >> Hi Vadim, >> >> "Pushtaev Vadim via RT" >> writes: >> >> > Hi! >> > >> > Since the last update, DBIx::Class::Schema::Loader automatically >> > creates `view_definition` for views. In case of MySQL it uses `SELECT >> > view_definition FROM information_schema.views ...` query and the >> > result of this query contains the database name along with every table >> > name: `project`.`user` instead of just `user`. >> >> Schema::Loader does deliberately not do anything with the view >> definition SQL, since that would require a fully-fledged SQL parser. >> This is incidentally why it does not introspect the view definition for >> DB2, since that only gives you the whole CREATE VIEW statement, not the >> body separately. >> >> > It's a big issue for our project since different users and >> > environments use different database names. It would be great to have >> > view definition without database name or at least disable >> > view_definition generation at all. >> >> For non-virtual views, the view definition is only used for ->deploy. >> The fact that you're happy with not having it generated at all makes it >> seem to me that you're not using deploy, so the definition is purely >> informative. >> >> If you really need it, you can add an sqlt_deploy_hook method to the >> result class that modifies $view->sql as appropriate for your specific >> case. >> >> Hope this helps, >> >> 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 ``` -- Reply to this email directly or view it on GitHub: https://github.com/dbsrgits/dbix-class-schema-loader/issues/51 You are receiving this because you are subscribed to this thread. Message ID: ----==_mimepart_637a937d8d2f5_418bc6701972977 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

Migrated from rt.cpan.org#119996 (status was 'open')

Requestors:

From pushtaev at cpan.org on 2017-01-26 13:26:44
:

Hi!

Since the last update, DBIx::Class::Schema::Loader automatically creates `view_definition` for views. In case of MySQL it uses `SELECT view_definition FROM information_schema.views ...` query and the result of this query contains the database name along with every table name: `project`.`user` instead of just `user`.

It's a big issue for our project since different users and environments use different database names. It would be great to have view definition without database name or at least disable view_definition generation at all.

Thank you!

From ilmari at ilmari.org on 2017-01-26 18:27:15
:

Hi Vadim,

"Pushtaev Vadim via RT" <bug-DBIx-Class-Schema-Loader at rt.cpan.org>
writes:

> Hi!
>
> Since the last update, DBIx::Class::Schema::Loader automatically
> creates `view_definition` for views. In case of MySQL it uses `SELECT
> view_definition FROM information_schema.views ...` query and the
> result of this query contains the database name along with every table
> name: `project`.`user` instead of just `user`.

Schema::Loader does deliberately not do anything with the view
definition SQL, since that would require a fully-fledged SQL parser.
This is incidentally why it does not introspect the view definition for
DB2, since that only gives you the whole CREATE VIEW statement, not the
body separately.

> It's a big issue for our project since different users and
> environments use different database names. It would be great to have
> view definition without database name or at least disable
> view_definition generation at all.

For non-virtual views, the view definition is only used for ->deploy.
The fact that you're happy with not having it generated at all makes it
seem to me that you're not using deploy, so the definition is purely
informative.

If you really need it, you can add an sqlt_deploy_hook method to the
result class that modifies $view->sql as appropriate for your specific
case.

Hope this helps,

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

From pushtaev at cpan.org on 2017-01-26 20:06:48
:

We do use `deploy` indeed. Previously we just added view_definition manually, but we would be happy to use auto-generated one (we have already monkey-patched Schema::Loader not to generate view_definiton as a workaround).

I understand you don't want to parse SQL, but there is a way to get view definition from MySQL without database name: https://dev.mysql.com/doc/refman/5.7/en/show-create-view.html

On Thu Jan 26 13:27:15 2017, ilmari at ilmari.org wrote:
> Hi Vadim,
> 
> "Pushtaev Vadim via RT" <bug-DBIx-Class-Schema-Loader at rt.cpan.org>
> writes:
> 
> > Hi!
> >
> > Since the last update, DBIx::Class::Schema::Loader automatically
> > creates `view_definition` for views. In case of MySQL it uses `SELECT
> > view_definition FROM information_schema.views ...` query and the
> > result of this query contains the database name along with every table
> > name: `project`.`user` instead of just `user`.
> 
> Schema::Loader does deliberately not do anything with the view
> definition SQL, since that would require a fully-fledged SQL parser.
> This is incidentally why it does not introspect the view definition for
> DB2, since that only gives you the whole CREATE VIEW statement, not the
> body separately.
> 
> > It's a big issue for our project since different users and
> > environments use different database names. It would be great to have
> > view definition without database name or at least disable
> > view_definition generation at all.
> 
> For non-virtual views, the view definition is only used for ->deploy.
> The fact that you're happy with not having it generated at all makes it
> seem to me that you're not using deploy, so the definition is purely
> informative.
> 
> If you really need it, you can add an sqlt_deploy_hook method to the
> result class that modifies $view->sql as appropriate for your specific
> case.
> 
> Hope this helps,
> 
> Ilmari
> 


From ilmari at ilmari.org on 2017-01-27 12:28:53
:

"Pushtaev Vadim via RT" <bug-DBIx-Class-Schema-Loader at rt.cpan.org>
writes:

> We do use `deploy` indeed. Previously we just added view_definition
> manually, but we would be happy to use auto-generated one (we have
> already monkey-patched Schema::Loader not to generate view_definiton
> as a workaround).


> I understand you don't want to parse SQL, but there is a way to get
> view definition from MySQL without database name:
> https://dev.mysql.com/doc/refman/5.7/en/show-create-view.html

That has the same problem as DB2: It includes the whole CREATE VIEW
statement, not just the query.  Also, whether it includes the database
name (which is really the schema, in standard SQL parlance) depends on
whether your current schema matches the one of the (tables used) in the
view.

mysql> \r test
mysql> show create view test.bar \G
*************************** 1. row ***************************
                View: bar
         Create View: CREATE ALGORITHM=UNDEFINED
                      DEFINER=`ilmari`@`%` SQL SECURITY DEFINER VIEW
                      `bar` AS select `foo`.`id` AS `id` from `foo`
character_set_client: utf8
collation_connection: utf8_general_ci
1 row in set (0.00 sec)

mysql> \r dbictest
mysql> show create view test.bar \G
*************************** 1. row ***************************
                View: bar
         Create View: CREATE ALGORITHM=UNDEFINED
                      DEFINER=`ilmari`@`%` SQL SECURITY DEFINER VIEW
                      `test`.`bar` AS select `test`.`foo`.`id` AS
                      `id` from `test`.`foo`
character_set_client: utf8
collation_connection: utf8_general_ci
1 row in set (0.00 sec)

> On Thu Jan 26 13:27:15 2017, ilmari at ilmari.org wrote:
>> Hi Vadim,
>> 
>> "Pushtaev Vadim via RT" <bug-DBIx-Class-Schema-Loader at rt.cpan.org>
>> writes:
>> 
>> > Hi!
>> >
>> > Since the last update, DBIx::Class::Schema::Loader automatically
>> > creates `view_definition` for views. In case of MySQL it uses `SELECT
>> > view_definition FROM information_schema.views ...` query and the
>> > result of this query contains the database name along with every table
>> > name: `project`.`user` instead of just `user`.
>> 
>> Schema::Loader does deliberately not do anything with the view
>> definition SQL, since that would require a fully-fledged SQL parser.
>> This is incidentally why it does not introspect the view definition for
>> DB2, since that only gives you the whole CREATE VIEW statement, not the
>> body separately.
>> 
>> > It's a big issue for our project since different users and
>> > environments use different database names. It would be great to have
>> > view definition without database name or at least disable
>> > view_definition generation at all.
>> 
>> For non-virtual views, the view definition is only used for ->deploy.
>> The fact that you're happy with not having it generated at all makes it
>> seem to me that you're not using deploy, so the definition is purely
>> informative.
>> 
>> If you really need it, you can add an sqlt_deploy_hook method to the
>> result class that modifies $view->sql as appropriate for your specific
>> case.
>> 
>> Hope this helps,
>> 
>> 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


Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.Message ID: <dbsrgits/dbix-class-schema-loader/issues/51@github.com>

----==_mimepart_637a937d8d2f5_418bc6701972977-- From notifications at github.com Sun Nov 20 20:52:28 2022 From: notifications at github.com (Veesh Goldman) Date: Sun, 20 Nov 2022 12:52:28 -0800 Subject: [DBIx-Class-Devel] [dbsrgits/dbix-class-schema-loader] Enums types are not properly create when unicode character is used [rt.cpan.org #123698] (Issue #52) Message-ID: Migrated from [rt.cpan.org#123698](https://rt.cpan.org/Ticket/Display.html?id=123698) (status was 'open') Requestors: * felix.ostmann at gmail.com From bogus@does.not.exist.com Sun Nov 20 20:48:46 2022 From: bogus@does.not.exist.com () Date: Sun, 20 Nov 2022 20:48:46 -0000 Subject: No subject Message-ID: ```=0D The {extra}{list} enum values are not correct encoded. I use the same con= nection settings for the app itself and all data from the database are co= rrectly encoded except this enum.=0D =0D =0D > \dT+=0D ...=0D steinhaus_main | enum_tasks_status | enum_tasks_status | 4 | off= en +| =0D | | | | erl= edigt +| =0D | | | | zur= =C3=83=C2=BCckgestellt | =0D ...=0D =0D =0D $ grep status -C5 Tasks.pm=0D ...=0D "status",=0D {=0D data_type =3D> "enum",=0D default_value =3D> "offen",=0D extra =3D> {=0D custom_type_name =3D> "enum_tasks_status",=0D list =3D> ["offen", "erledigt", "zur\xFCckgestellt"],=0D },=0D is_nullable =3D> 0,=0D },=0D ...=0D =0D the file is in utf8 with use utf8; in the beginning so i expected:=0D =0D list =3D> ["offen", "erledigt", "zur=C3=83=C2=BCckgestellt"],=0D ```=0D =0D From bogus@does.not.exist.com Sun Nov 20 20:48:46 2022 From: bogus@does.not.exist.com () Date: Sun, 20 Nov 2022 20:48:46 -0000 Subject: No subject Message-ID: ```=0D On 2017-11-21 09:54:01, felix.ostmann at gmail.com wrote:=0D > The {extra}{list} enum values are not correct encoded. I use the same=0D= > connection settings for the app itself and all data from the database=0D= > are correctly encoded except this enum.=0D > =0D > =0D > > \dT+=0D > ...=0D > steinhaus_main | enum_tasks_status | enum_tasks_status | 4 |=0D= > offen +|=0D > | | | |=0D= > erledigt +|=0D > | | | |=0D= > zur=C3=83=C2=BCckgestellt |=0D > ...=0D > =0D > =0D > $ grep status -C5 Tasks.pm=0D > ...=0D > "status",=0D > {=0D > data_type =3D> "enum",=0D > default_value =3D> "offen",=0D > extra =3D> {=0D > custom_type_name =3D> "enum_tasks_status",=0D > list =3D> ["offen", "erledigt", "zur\xFCckgestellt"],=0D > },=0D > is_nullable =3D> 0,=0D > },=0D > ...=0D > =0D > the file is in utf8 with use utf8; in the beginning so i expected:=0D > =0D > list =3D> ["offen", "erledigt", "zur=C3=83=C2=BCckgestellt"],=0D =0D These representations of the string are equivalent:=0D =0D $ perl -Mutf8 -E 'say "zur\xFCckgestellt" eq "zur=C3=83=C2=BCckgestel= lt"'=0D 1=0D =0D Schema::Loader uses Data::Dump to serialise method call arguments in the = generated files, and it encodes all non-ASCII (and non-printable) charact= ers using \x notation.=0D =0D For aesthetic reasons it might be desirable to output Unicode word charac= ters literally too, but the current output is not incorrect.=0D =0D - ilmari=0D ```=0D =0D From bogus@does.not.exist.com Sun Nov 20 20:48:46 2022 From: bogus@does.not.exist.com () Date: Sun, 20 Nov 2022 20:48:46 -0000 Subject: No subject Message-ID: ```=0D Am Di 21. Nov 2017, 06:08:27, ilmari schrieb:=0D > On 2017-11-21 09:54:01, felix.ostmann at gmail.com wrote:=0D > > The {extra}{list} enum values are not correct encoded. I use the same= =0D > > connection settings for the app itself and all data from the database= =0D > > are correctly encoded except this enum.=0D > >=0D > >=0D > > > \dT+=0D > > ...=0D > > steinhaus_main | enum_tasks_status | enum_tasks_status | 4=0D > > |=0D > > offen +|=0D > > | | |=0D > > |=0D > > erledigt +|=0D > > | | |=0D > > |=0D > > zur=C3=83=C2=BCckgestellt |=0D > > ...=0D > >=0D > >=0D > > $ grep status -C5 Tasks.pm=0D > > ...=0D > > "status",=0D > > {=0D > > data_type =3D> "enum",=0D > > default_value =3D> "offen",=0D > > extra =3D> {=0D > > custom_type_name =3D> "enum_tasks_status",=0D > > list =3D> ["offen", "erledigt", "zur\xFCckgestellt"],=0D > > },=0D > > is_nullable =3D> 0,=0D > > },=0D > > ...=0D > >=0D > > the file is in utf8 with use utf8; in the beginning so i expected:=0D= > >=0D > > list =3D> ["offen", "erledigt", "zur=C3=83=C2=BCckgestellt"],=0D > =0D > These representations of the string are equivalent:=0D > =0D > $ perl -Mutf8 -E 'say "zur\xFCckgestellt" eq "zur=C3=83=C2=BCckgestellt= "'=0D > 1=0D > =0D > Schema::Loader uses Data::Dump to serialise method call arguments in=0D= > the generated files, and it encodes all non-ASCII (and non-printable)=0D= > characters using \x notation.=0D > =0D > For aesthetic reasons it might be desirable to output Unicode word=0D > characters literally too, but the current output is not incorrect.=0D > =0D > - ilmari=0D =0D It is not really the same ...=0D =0D In the real code i have to make a Encode::decode('ISO-8859-15', $enum) as= a quickfix. =0D =0D $ cat ticket123698.pl =0D use utf8;=0D use 5.20.0;=0D use Data::Dumper;=0D say "zur\xFCckgestellt" eq "zur=C3=83=C2=BCckgestellt";=0D print Dumper("zur\xFCckgestellt","zur=C3=83=C2=BCckgestellt");=0D $ perl ticket123698.pl =0D 1=0D $VAR1 =3D 'zur=C3=AF=C2=BF=C2=BDckgestellt';=0D $VAR2 =3D "zur\x{fc}ckgestellt";=0D ```=0D =0D From bogus@does.not.exist.com Sun Nov 20 20:48:46 2022 From: bogus@does.not.exist.com () Date: Sun, 20 Nov 2022 20:48:46 -0000 Subject: No subject Message-ID: ```=0D "Felix Antonius Wilhelm Ostmann via RT"=0D writes:=0D =0D > It is not really the same ...=0D =0D The _internal_ representation is not the same; the \x from will be=0D represented internally as one byte per code point ("downgraded"), while=0D= the literal form will be utf-8-encoded ("upgraded"). Semantically they=0D= are the same, as evidenced by "eq" returning true.=0D =0D > In the real code i have to make a Encode::decode('ISO-8859-15', $enum) = as a quickfix. =0D =0D Please show where in the real code you have to do this. It smells like=0D= something you're passing it to suffering from the Unicode Bug,=0D i.e. treating the characters in the 128..255 range differently depending=0D= on the internal representation (see=0D https://metacpan.org/pod/perlunicode#The-%22Unicode-Bug%22 for details).=0D= =0D > $ cat ticket123698.pl =0D > use utf8;=0D > use 5.20.0;=0D > use Data::Dumper;=0D > say "zur\xFCckgestellt" eq "zur=C3=83=C2=BCckgestellt";=0D > print Dumper("zur\xFCckgestellt","zur=C3=83=C2=BCckgestellt");=0D > $ perl ticket123698.pl =0D > 1=0D > $VAR1 =3D 'zur=C3=AF=C2=BF=C2=BDckgestellt';=0D > $VAR2 =3D "zur\x{fc}ckgestellt";=0D =0D The different outputs here are a quirk of how Data::Dumper deals with=0D downgraded vs. upgraded strings (which could be viewed as an instance of=0D= the Unicode Bug, but doesn't actually affect semantics). The first one=0D= is showing as =C3=AF=C2=BF=C2=BD because you haven't thold perl that your= terminal=0D expects UTF-8-encoded strings. Adding=0D =0D use open qw(:std :utf8);=0D =0D to the script will make it apply a UTF-8 encoding layer to the standard=0D= input/output/error filehandles, so non-ASCII charcters show correctly.=0D= =0D - ilmari=0D -- =0D "I use RMS as a guide in the same way that a boat captain would use=0D a lighthouse. It's good to know where it is, but you generally=0D don't want to find yourself in the same spot." - Tollef Fog Heen=0D ```=0D =0D From bogus@does.not.exist.com Sun Nov 20 20:48:46 2022 From: bogus@does.not.exist.com () Date: Sun, 20 Nov 2022 20:48:46 -0000 Subject: No subject Message-ID: ```=0D Am Di 21. Nov 2017, 07:07:59, ilmari at ilmari.org schrieb:=0D > "Felix Antonius Wilhelm Ostmann via RT"=0D > writes:=0D > =0D > > It is not really the same ...=0D > =0D > The _internal_ representation is not the same; the \x from will be=0D > represented internally as one byte per code point ("downgraded"),=0D > while=0D > the literal form will be utf-8-encoded ("upgraded"). Semantically they=0D= > are the same, as evidenced by "eq" returning true.=0D > =0D > > In the real code i have to make a Encode::decode('ISO-8859-15',=0D > > $enum) as a quickfix.=0D > =0D > Please show where in the real code you have to do this. It smells=0D > like=0D > something you're passing it to suffering from the Unicode Bug,=0D > i.e. treating the characters in the 128..255 range differently=0D > depending=0D > on the internal representation (see=0D > https://metacpan.org/pod/perlunicode#The-%22Unicode-Bug%22 for=0D > details).=0D > =0D > > $ cat ticket123698.pl=0D > > use utf8;=0D > > use 5.20.0;=0D > > use Data::Dumper;=0D > > say "zur\xFCckgestellt" eq "zur=C3=83=C2=BCckgestellt";=0D > > print Dumper("zur\xFCckgestellt","zur=C3=83=C2=BCckgestellt");=0D > > $ perl ticket123698.pl=0D > > 1=0D > > $VAR1 =3D 'zur=C3=AF=C2=BF=C2=BDckgestellt';=0D > > $VAR2 =3D "zur\x{fc}ckgestellt";=0D > =0D > The different outputs here are a quirk of how Data::Dumper deals with=0D= > downgraded vs. upgraded strings (which could be viewed as an instance=0D= > of=0D > the Unicode Bug, but doesn't actually affect semantics). The first=0D > one=0D > is showing as =C3=AF=C2=BF=C2=BD because you haven't thold perl that yo= ur terminal=0D > expects UTF-8-encoded strings. Adding=0D > =0D > use open qw(:std :utf8);=0D > =0D > to the script will make it apply a UTF-8 encoding layer to the=0D > standard=0D > input/output/error filehandles, so non-ASCII charcters show correctly.=0D= > =0D > - ilmari=0D =0D =0D OK, here is the real world scenario with pseudo code. I am using DBIx::Cl= ass + Catalyst + Template Toolkit=0D =0D ResultSet:=0D sub enum_status {=0D my ($self) =3D @_;=0D # FIXME see https://rt.cpan.org/Public/Bug/Update.html?id=3D123698=0D= return map { Encode::decode("ISO-8859-15", $_) } @{ $self->result_sou= rce->column_info('status')->{extra}->{list} };=0D return @{ $self->result_source->column_info('status')->{extra}->{list= } };=0D }=0D =0D Catalyst-Controller:=0D $c->stash->{status_order} =3D [ $rs->enum_status ];=0D =0D Template:=0D [% FOREACH status IN status_order %]=0D status}) %]">=0D [% END %]=0D =0D Without the FIXME the links are ISO-8859-15=0D =0D =0D After reading your reply and docs about unicode-Bug i changed the code to= the following:=0D =0D __PACKAGE__->column_adds(=0D ...=0D { =0D data_type =3D> "enum",=0D default_value =3D> "offen", =0D extra =3D> {=0D custom_type_name =3D> "enum_tasks_status",=0D list =3D> ["offen", "erledigt", "zur\xFCckgestellt"],=0D }, =0D is_nullable =3D> 0, =0D },=0D ...=0D );=0D ...=0D # DO NOT MODIFY THIS OR ANYTHING ABOVE! md5sum:W4KhHAXiEW35h5XWiZwhFg=0D utf8::upgrade($_) for @{ __PACKAGE__->column_info('status')->{extra}->{li= st} };=0D =0D =0D =0D But in my option this is kind of a bug. Why are all other strings comming= from the database already upgraded but not this?=0D =0D =0D ```=0D =0D =0D -- =0D Reply to this email directly or view it on GitHub:=0D https://github.com/dbsrgits/dbix-class-schema-loader/issues/52=0D You are receiving this because you are subscribed to this thread.=0D =0D Message ID: = ----==_mimepart_637a938c595dd_1b82c67021831f3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

=0D

Migrated from rt.cpan.org#123698 (status was = 'open')

=0D

Requestors:

=0D =0D

From felix.ost= mann at gmail.com on 2017-11-21 09:54:01
=0D :

=0D
The {extra}{list} =
enum values are not correct encoded. I use the same connection settings f=
or the app itself and all data from the database are correctly encoded ex=
cept this enum.=0D
=0D
=0D
> \dT+=0D
...=0D
 steinhaus_main | enum_tasks_status   | enum_tasks_status   | 4     | off=
en         +| =0D
                |                     |                     |       | erl=
edigt      +| =0D
                |                     |                     |       | zur=
=C3=83=C2=BCckgestellt | =0D
...=0D
=0D
=0D
$ grep status -C5 Tasks.pm=0D
...=0D
  "status",=0D
  {=0D
    data_type =3D> "enum",=0D
    default_value =3D> "offen",=0D
    extra =3D> {=0D
      custom_type_name =3D> "enum_tasks_status",=0D
      list =3D> ["offen", "erledigt", "zur\xFCckgestellt"],=0D
    },=0D
    is_nullable =3D> 0,=0D
  },=0D
...=0D
=0D
the file is in utf8 with use utf8; in the beginning so i expected:=0D
=0D
      list =3D> ["offen", "erledigt", "zur=C3=83=C2=BCckgestellt"],=0D=

=0D

From ilmari+cpa= n at ilmari.org on 2017-11-21 11:08:27
=0D :

=0D
On 2017-11-21 09:5=
4:01, felix.ostmann at gmail.com wrote:=0D
> The {extra}{list} enum values are not correct encoded. I use the sam=
e=0D
> connection settings for the app itself and all data from the databas=
e=0D
> are correctly encoded except this enum.=0D
> =0D
> =0D
> > \dT+=0D
> ...=0D
>   steinhaus_main | enum_tasks_status   | enum_tasks_status   | 4    =
 |=0D
> offen         +|=0D
>                  |                     |                     |      =
 |=0D
> erledigt      +|=0D
>                  |                     |                     |      =
 |=0D
> zur=C3=83=C2=BCckgestellt |=0D
> ...=0D
> =0D
> =0D
> $ grep status -C5 Tasks.pm=0D
> ...=0D
>   "status",=0D
>   {=0D
>     data_type =3D> "enum",=0D
>     default_value =3D> "offen",=0D
>     extra =3D> {=0D
>       custom_type_name =3D> "enum_tasks_status",=0D
>       list =3D> ["offen", "erledigt", "zur\xFCckgestellt"],=0D
>     },=0D
>     is_nullable =3D> 0,=0D
>   },=0D
> ...=0D
> =0D
> the file is in utf8 with use utf8; in the beginning so i expected:=0D=

> =0D
> list =3D> ["offen", "erledigt", "zur=C3=83=C2=BCckgestellt"],=0D
=0D
These representations of the string are equivalent:=0D
=0D
    $ perl -Mutf8 -E 'say "zur\xFCckgestellt" eq "zur=C3=83=C2=BCckgestel=
lt"'=0D
    1=0D
=0D
Schema::Loader uses Data::Dump to serialise method call arguments in the =
generated files, and it encodes all non-ASCII (and non-printable) charact=
ers using \x notation.=0D
=0D
For aesthetic reasons it might be desirable to output Unicode word charac=
ters literally too, but the current output is not incorrect.=0D
=0D
- ilmari=0D
=0D

From felix.ost= mann at gmail.com on 2017-11-21 11:43:13
=0D :

=0D
Am Di 21. Nov 2017=
, 06:08:27, ilmari schrieb:=0D
> On 2017-11-21 09:54:01, felix.ostmann at gmail.com wrote:=0D
> > The {extra}{list} enum values are not correct encoded. I use th=
e same=0D
> > connection settings for the app itself and all data from the da=
tabase=0D
> > are correctly encoded except this enum.=0D
> >=0D
> >=0D
> > > \dT+=0D
> > ...=0D
> >   steinhaus_main | enum_tasks_status   | enum_tasks_status   | =
4=0D
> > |=0D
> > offen         +|=0D
> >                  |                     |                     |=0D=

> > |=0D
> > erledigt      +|=0D
> >                  |                     |                     |=0D=

> > |=0D
> > zur=C3=83=C2=BCckgestellt |=0D
> > ...=0D
> >=0D
> >=0D
> > $ grep status -C5 Tasks.pm=0D
> > ...=0D
> >   "status",=0D
> >   {=0D
> >     data_type =3D> "enum",=0D
> >     default_value =3D> "offen",=0D
> >     extra =3D> {=0D
> >       custom_type_name =3D> "enum_tasks_status",=0D
> >       list =3D> ["offen", "erledigt", "zur\xFCckgestellt"],=0D=

> >     },=0D
> >     is_nullable =3D> 0,=0D
> >   },=0D
> > ...=0D
> >=0D
> > the file is in utf8 with use utf8; in the beginning so i expect=
ed:=0D
> >=0D
> > list =3D> ["offen", "erledigt", "zur=C3=83=C2=BCckgestellt"]=
,=0D
> =0D
> These representations of the string are equivalent:=0D
> =0D
> $ perl -Mutf8 -E 'say "zur\xFCckgestellt" eq "zur=C3=83=C2=BCckgeste=
llt"'=0D
> 1=0D
> =0D
> Schema::Loader uses Data::Dump to serialise method call arguments in=
=0D
> the generated files, and it encodes all non-ASCII (and non-printable=
)=0D
> characters using \x notation.=0D
> =0D
> For aesthetic reasons it might be desirable to output Unicode word=0D=

> characters literally too, but the current output is not incorrect.=0D=

> =0D
> - ilmari=0D
=0D
It is not really the same ...=0D
=0D
In the real code i have to make a Encode::decode('ISO-8859-15', $enum) as=
 a quickfix. =0D
=0D
$ cat ticket123698.pl =0D
use utf8;=0D
use 5.20.0;=0D
use Data::Dumper;=0D
say "zur\xFCckgestellt" eq "zur=C3=83=C2=BCckgestellt";=0D
print Dumper("zur\xFCckgestellt","zur=C3=83=C2=BCckgestellt");=0D
$ perl ticket123698.pl =0D
1=0D
$VAR1 =3D 'zur=C3=AF=C2=BF=C2=BDckgestellt';=0D
$VAR2 =3D "zur\x{fc}ckgestellt";=0D
=0D

From ilmari at ilmari.o= rg on 2017-11-21 12:07:59
=0D :

=0D
"Felix Antonius Wi=
lhelm Ostmann via RT"=0D
<bug-DBIx-Class-Schema-Loader at rt.cpan.org> writes:=0D
=0D
> It is not really the same ...=0D
=0D
The _internal_ representation is not the same; the \x from will be=0D
represented internally as one byte per code point ("downgraded"), while=0D=

the literal form will be utf-8-encoded ("upgraded"). Semantically they=0D=

are the same, as evidenced by "eq" returning true.=0D
=0D
> In the real code i have to make a Encode::decode('ISO-8859-15', $enu=
m) as a quickfix. =0D
=0D
Please show where in the real code you have to do this.  It smells like=0D=

something you're passing it to suffering from the Unicode Bug,=0D
i.e. treating the characters in the 128..255 range differently depending=0D=

on the internal representation (see=0D
https://metacpan.org/pod/perlunicode#The-%22Unicode-Bug%22 for details).=0D=

=0D
> $ cat ticket123698.pl =0D
> use utf8;=0D
> use 5.20.0;=0D
> use Data::Dumper;=0D
> say "zur\xFCckgestellt" eq "zur=C3=83=C2=BCckgestellt";=0D
> print Dumper("zur\xFCckgestellt","zur=C3=83=C2=BCckgestellt");=0D
> $ perl ticket123698.pl =0D
> 1=0D
> $VAR1 =3D 'zur=C3=AF=C2=BF=C2=BDckgestellt';=0D
> $VAR2 =3D "zur\x{fc}ckgestellt";=0D
=0D
The different outputs here are a quirk of how Data::Dumper deals with=0D
downgraded vs. upgraded strings (which could be viewed as an instance of=0D=

the Unicode Bug, but doesn't actually affect semantics).  The first one=0D=

is showing as =C3=AF=C2=BF=C2=BD because you haven't thold perl that your=
 terminal=0D
expects UTF-8-encoded strings.  Adding=0D
=0D
    use open qw(:std :utf8);=0D
=0D
to the script will make it apply a UTF-8 encoding layer to the standard=0D=

input/output/error filehandles, so non-ASCII charcters show correctly.=0D=

=0D
- ilmari=0D
-- =0D
"I use RMS as a guide in the same way that a boat captain would use=0D
 a lighthouse.  It's good to know where it is, but you generally=0D
 don't want to find yourself in the same spot." - Tollef Fog Heen=0D
=0D

From felix.ost= mann at gmail.com on 2017-11-21 13:35:39
=0D :

=0D
Am Di 21. Nov 2017=
, 07:07:59, ilmari at ilmari.org schrieb:=0D
> "Felix Antonius Wilhelm Ostmann via RT"=0D
> <bug-DBIx-Class-Schema-Loader at rt.cpan.org> writes:=0D
> =0D
> > It is not really the same ...=0D
> =0D
> The _internal_ representation is not the same; the \x from will be=0D=

> represented internally as one byte per code point ("downgraded"),=0D=

> while=0D
> the literal form will be utf-8-encoded ("upgraded"). Semantically th=
ey=0D
> are the same, as evidenced by "eq" returning true.=0D
> =0D
> > In the real code i have to make a Encode::decode('ISO-8859-15',=
=0D
> > $enum) as a quickfix.=0D
> =0D
> Please show where in the real code you have to do this.  It smells=0D=

> like=0D
> something you're passing it to suffering from the Unicode Bug,=0D
> i.e. treating the characters in the 128..255 range differently=0D
> depending=0D
> on the internal representation (see=0D
> https://metacpan.org/pod/perlunicode#The-%22Unicode-Bug%22 for=0D
> details).=0D
> =0D
> > $ cat ticket123698.pl=0D
> > use utf8;=0D
> > use 5.20.0;=0D
> > use Data::Dumper;=0D
> > say "zur\xFCckgestellt" eq "zur=C3=83=C2=BCckgestellt";=0D
> > print Dumper("zur\xFCckgestellt","zur=C3=83=C2=BCckgestellt");=0D=

> > $ perl ticket123698.pl=0D
> > 1=0D
> > $VAR1 =3D 'zur=C3=AF=C2=BF=C2=BDckgestellt';=0D
> > $VAR2 =3D "zur\x{fc}ckgestellt";=0D
> =0D
> The different outputs here are a quirk of how Data::Dumper deals wit=
h=0D
> downgraded vs. upgraded strings (which could be viewed as an instanc=
e=0D
> of=0D
> the Unicode Bug, but doesn't actually affect semantics).  The first=0D=

> one=0D
> is showing as =C3=AF=C2=BF=C2=BD because you haven't thold perl that=
 your terminal=0D
> expects UTF-8-encoded strings.  Adding=0D
> =0D
> use open qw(:std :utf8);=0D
> =0D
> to the script will make it apply a UTF-8 encoding layer to the=0D
> standard=0D
> input/output/error filehandles, so non-ASCII charcters show correctl=
y.=0D
> =0D
> - ilmari=0D
=0D
=0D
OK, here is the real world scenario with pseudo code. I am using DBIx::Cl=
ass + Catalyst + Template Toolkit=0D
=0D
ResultSet:=0D
sub enum_status {=0D
    my ($self) =3D @_;=0D
    # FIXME see https://rt.cpan.org/Public/Bug/Update.html?id=3D123698=0D=

    return map { Encode::decode("ISO-8859-15", $_) } @{ $self->result_=
source->column_info('status')->{extra}->{list} };=0D
    return @{ $self->result_source->column_info('status')->{extr=
a}->{list} };=0D
}=0D
=0D
Catalyst-Controller:=0D
$c->stash->{status_order} =3D [ $rs->enum_status ];=0D
=0D
Template:=0D
[% FOREACH status IN status_order %]=0D
<a href=3D"[% c.request.uri_with({status =3D> status}) %]">=0D
[% END %]=0D
=0D
Without the FIXME the links are ISO-8859-15=0D
=0D
=0D
After reading your reply and docs about unicode-Bug i changed the code to=
 the following:=0D
=0D
__PACKAGE__->column_adds(=0D
...=0D
  {         =0D
    data_type =3D> "enum",=0D
    default_value =3D> "offen",  =0D
    extra =3D> {=0D
      custom_type_name =3D> "enum_tasks_status",=0D
      list =3D> ["offen", "erledigt", "zur\xFCckgestellt"],=0D
    },      =0D
    is_nullable =3D> 0,          =0D
  },=0D
...=0D
);=0D
...=0D
# DO NOT MODIFY THIS OR ANYTHING ABOVE! md5sum:W4KhHAXiEW35h5XWiZwhFg=0D
utf8::upgrade($_) for @{ __PACKAGE__->column_info('status')->{extra=
}->{list} };=0D
=0D
=0D
=0D
But in my option this is kind of a bug. Why are all other strings comming=
 from the database already upgraded but not this?=0D
=0D
=0D
=0D =0D

&m= dash;
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receivi= ng this because you are subscribed to this thread.3D""Message I= D: <dbsrgits/dbix-class-schema-loader/issues/52@github.com>

=0D = ----==_mimepart_637a938c595dd_1b82c67021831f3-- From notifications at github.com Sun Nov 20 20:52:40 2022 From: notifications at github.com (Veesh Goldman) Date: Sun, 20 Nov 2022 12:52:40 -0800 Subject: [DBIx-Class-Devel] [dbsrgits/dbix-class-schema-loader] pluralization not complete [rt.cpan.org #125930] (Issue #53) Message-ID: Migrated from [rt.cpan.org#125930](https://rt.cpan.org/Ticket/Display.html?id=125930) (status was 'open') Requestors: * ether at cpan.org From bogus@does.not.exist.com Sun Nov 20 20:48:46 2022 From: bogus@does.not.exist.com () Date: Sun, 20 Nov 2022 20:48:46 -0000 Subject: No subject Message-ID: ``` I have a table called "device_criteria". Even with naming => { ALL => 'v8', force_ascii => 1 } in my config file, I end up with a source called DeviceCriteria, not DeviceCriterion. this looks to be the root problem: perl -MLingua::EN::Inflect::Phrase -wle'print Lingua::EN::Inflect::Phrase::to_S("device_criteria");' -> device_criteria I guess some splitting into words is required first? ``` From bogus@does.not.exist.com Sun Nov 20 20:48:46 2022 From: bogus@does.not.exist.com () Date: Sun, 20 Nov 2022 20:48:46 -0000 Subject: No subject Message-ID: ``` "Karen Etheridge via RT" writes: > I have a table called "device_criteria". Even with naming => { ALL => 'v8', force_ascii => 1 } > in my config file, I end up with a source called DeviceCriteria, not DeviceCriterion. > > this looks to be the root problem: > > perl -MLingua::EN::Inflect::Phrase -wle'print Lingua::EN::Inflect::Phrase::to_S("device_criteria");' > -> device_criteria > > I guess some splitting into words is required first? That wouldn't help, Lingua::EN::Inflect::Phrase doesn't handle "criteria" on its own either. $ perl -MLingua::EN::Inflect::Phrase -wle'print Lingua::EN::Inflect::Phrase::to_S("criteria");' criteria The underlying problem seems to be that Lingua::EN::Inflect::Number thinks 'criteria' is already singular: $ perl -MLingua::EN::Inflect::Number=number -E 'say number "criteria"' s I think this all stems from the fact hat Lingua::EN::Inflect::Number abuses Lingua::EN::Inflect::PL() to convert to _singular_, which is documented as "undefined (and unlikely to be correct)", the comment in to_S() even says "I don't know why this works, but it seems to." Lingua::EN::Inflect does know to pluralise "criterion" to "criteria", but the usual (accidental?) behaviour of PL() singularising already-plural words doesn't seem to apply to it (or other "ion" -> "a" words like "aphelion"). Lingua::EN::Inflect::Phrase does have a bunch of special cases, I guess this could be added there. -ilmari ``` From bogus@does.not.exist.com Sun Nov 20 20:48:46 2022 From: bogus@does.not.exist.com () Date: Sun, 20 Nov 2022 20:48:46 -0000 Subject: No subject Message-ID: ``` Is this being rejected because (seemingly) Lingua::* doesn't know how to handle this word? On 2018-07-26 03:16:47, ilmari wrote: > > I guess some splitting into words is required first? > > That wouldn't help, Lingua::EN::Inflect::Phrase doesn't handle > "criteria" on its own either. This works (and indeed is what I'm doing elsewhere in the codebase: use Lingua::EN::Inflexion 'noun'; my $table_name = 'device_criteria'; my @words = split('_', $table_name); $words[-1] = noun($words[-1])->singular; my $source = camelize(join('_', @words)); perl -MLingua::EN::Inflexion=noun -wle'print noun("criteria")->singular' --> criterion ``` -- Reply to this email directly or view it on GitHub: https://github.com/dbsrgits/dbix-class-schema-loader/issues/53 You are receiving this because you are subscribed to this thread. Message ID: ----==_mimepart_637a9398219a7_7f0fc670206786a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

Migrated from rt.cpan.org#125930 (status was 'open')

Requestors:

From ether at cpan.org on 2018-07-25 16:39:52
:

I have a table called "device_criteria". Even with naming => { ALL => 'v8', force_ascii => 1 } in my config file, I end up with a source called DeviceCriteria, not DeviceCriterion.

this looks to be the root problem:

perl -MLingua::EN::Inflect::Phrase -wle'print Lingua::EN::Inflect::Phrase::to_S("device_criteria");'
-> device_criteria

I guess some splitting into words is required first?

From ilmari+cpan at ilmari.org on 2018-07-26 10:16:47
:

"Karen Etheridge via RT" <bug-DBIx-Class-Schema-Loader at rt.cpan.org>
writes:

> I have a table called "device_criteria". Even with naming => { ALL => 'v8', force_ascii => 1 }
> in my config file, I end up with a source called DeviceCriteria, not DeviceCriterion.
>
> this looks to be the root problem:
>
> perl -MLingua::EN::Inflect::Phrase -wle'print Lingua::EN::Inflect::Phrase::to_S("device_criteria");'
> -> device_criteria
>
> I guess some splitting into words is required first?

That wouldn't help, Lingua::EN::Inflect::Phrase doesn't handle "criteria" on its own either.

$ perl -MLingua::EN::Inflect::Phrase -wle'print Lingua::EN::Inflect::Phrase::to_S("criteria");'
criteria

The underlying problem seems to be that Lingua::EN::Inflect::Number
thinks 'criteria' is already singular:

$ perl -MLingua::EN::Inflect::Number=number -E 'say number "criteria"'
s

I think this all stems from the fact hat Lingua::EN::Inflect::Number
abuses Lingua::EN::Inflect::PL() to convert to _singular_, which is
documented as "undefined (and unlikely to be correct)", the comment in
to_S() even says "I don't know why this works, but it seems to."

Lingua::EN::Inflect does know to pluralise "criterion" to "criteria",
but the usual (accidental?) behaviour of PL() singularising already-plural
words doesn't seem to apply to it (or other "ion" -> "a" words like "aphelion").

Lingua::EN::Inflect::Phrase does have a bunch of special cases, I guess this
could be added there.

-ilmari

From ether at cpan.org on 2018-07-26 15:22:31
:

Is this being rejected because (seemingly) Lingua::* doesn't know how to handle this word?

On 2018-07-26 03:16:47, ilmari wrote:

> > I guess some splitting into words is required first?
> 
> That wouldn't help, Lingua::EN::Inflect::Phrase doesn't handle
> "criteria" on its own either.

This works (and indeed is what I'm doing elsewhere in the codebase:

    use Lingua::EN::Inflexion 'noun';
    my $table_name = 'device_criteria';
    my @words = split('_', $table_name);
    $words[-1] = noun($words[-1])->singular;
    my $source = camelize(join('_', @words));

perl -MLingua::EN::Inflexion=noun -wle'print noun("criteria")->singular'
--> criterion


Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.Message ID: <dbsrgits/dbix-class-schema-loader/issues/53@github.com>

----==_mimepart_637a9398219a7_7f0fc670206786a-- From notifications at github.com Mon Nov 21 01:32:15 2022 From: notifications at github.com (Mike Bruins) Date: Sun, 20 Nov 2022 17:32:15 -0800 Subject: [DBIx-Class-Devel] [dbsrgits/dbix-class-schema-loader] Not recognising primary key automatically set with uuid_generate_v4() in PostgreSQL database [rt.cpan.org #143291] (Issue #28) In-Reply-To: References: Message-ID: This is still happening. Please help. Thanks -- Reply to this email directly or view it on GitHub: https://github.com/dbsrgits/dbix-class-schema-loader/issues/28#issuecomment-1321324761 You are receiving this because you are subscribed to this thread. Message ID: -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Mon Nov 21 16:21:20 2022 From: notifications at github.com (Veesh Goldman) Date: Mon, 21 Nov 2022 08:21:20 -0800 Subject: [DBIx-Class-Devel] [dbsrgits/dbix-class-schema-loader] Not recognising primary key automatically set with uuid_generate_v4() in PostgreSQL database [rt.cpan.org #143291] (Issue #28) In-Reply-To: References: Message-ID: Hi, could you post a copy of the generated class? It would help a lot, thanks -- Reply to this email directly or view it on GitHub: https://github.com/dbsrgits/dbix-class-schema-loader/issues/28#issuecomment-1322320444 You are receiving this because you are subscribed to this thread. Message ID: -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Mon Nov 21 21:19:59 2022 From: notifications at github.com (Mike Bruins) Date: Mon, 21 Nov 2022 13:19:59 -0800 Subject: [DBIx-Class-Devel] [dbsrgits/dbix-class-schema-loader] Not recognising primary key automatically set with uuid_generate_v4() in PostgreSQL database [rt.cpan.org #143291] (Issue #28) In-Reply-To: References: Message-ID: [Invoice.pm.txt](https://github.com/dbsrgits/dbix-class-schema-loader/files/10060569/Invoice.pm.txt) To upload I had to append ".txt" due to ".pm" extension not being supported upload type. -- Reply to this email directly or view it on GitHub: https://github.com/dbsrgits/dbix-class-schema-loader/issues/28#issuecomment-1322658540 You are receiving this because you are subscribed to this thread. Message ID: -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Wed Nov 23 18:41:23 2022 From: notifications at github.com (Veesh Goldman) Date: Wed, 23 Nov 2022 10:41:23 -0800 Subject: [DBIx-Class-Devel] [dbsrgits/dbix-class-schema-loader] Use retrieve_on_insert for defaulting PK cols (PR #54) Message-ID: closes #28 - feat: add retrieve_on_insert to all primary_keys generated from functions - feat: ensure new roi feature is tested You can view, comment on, or merge this pull request online at: https://github.com/dbsrgits/dbix-class-schema-loader/pull/54 -- Commit Summary -- * feat: add retrieve_on_insert to all primary_keys generated from functions * feat: ensure new roi feature is tested -- File Changes -- M lib/DBIx/Class/Schema/Loader/DBI/Pg.pm (12) M t/10_03pg_common.t (19) -- Patch Links -- https://github.com/dbsrgits/dbix-class-schema-loader/pull/54.patch https://github.com/dbsrgits/dbix-class-schema-loader/pull/54.diff -- Reply to this email directly or view it on GitHub: https://github.com/dbsrgits/dbix-class-schema-loader/pull/54 You are receiving this because you are subscribed to this thread. Message ID: <dbsrgits/dbix-class-schema-loader/pull/54 at github.com> -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Wed Nov 23 18:42:48 2022 From: notifications at github.com (Veesh Goldman) Date: Wed, 23 Nov 2022 10:42:48 -0800 Subject: [DBIx-Class-Devel] [dbsrgits/dbix-class-schema-loader] Use retrieve_on_insert for defaulting PK cols (PR #54) In-Reply-To: References: Message-ID: Merged #54 into master. -- Reply to this email directly or view it on GitHub: https://github.com/dbsrgits/dbix-class-schema-loader/pull/54#event-7879867774 You are receiving this because you are subscribed to this thread. Message ID: -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Wed Nov 23 18:42:49 2022 From: notifications at github.com (Veesh Goldman) Date: Wed, 23 Nov 2022 10:42:49 -0800 Subject: [DBIx-Class-Devel] [dbsrgits/dbix-class-schema-loader] Not recognising primary key automatically set with uuid_generate_v4() in PostgreSQL database [rt.cpan.org #143291] (Issue #28) In-Reply-To: References: Message-ID: Closed #28 as completed via #54. -- Reply to this email directly or view it on GitHub: https://github.com/dbsrgits/dbix-class-schema-loader/issues/28#event-7879867869 You are receiving this because you are subscribed to this thread. Message ID: -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Wed Nov 23 18:53:35 2022 From: notifications at github.com (Veesh Goldman) Date: Wed, 23 Nov 2022 10:53:35 -0800 Subject: [DBIx-Class-Devel] [dbsrgits/dbix-class-schema-loader] Not recognising primary key automatically set with uuid_generate_v4() in PostgreSQL database [rt.cpan.org #143291] (Issue #28) In-Reply-To: References: Message-ID: thanks so much for helping me to fix this. This should be fixed in the latest release (0.07051); let me know if otherwise -- Reply to this email directly or view it on GitHub: https://github.com/dbsrgits/dbix-class-schema-loader/issues/28#issuecomment-1325524005 You are receiving this because you are subscribed to this thread. Message ID: -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Wed Nov 23 20:58:02 2022 From: notifications at github.com (Mike Bruins) Date: Wed, 23 Nov 2022 12:58:02 -0800 Subject: [DBIx-Class-Devel] [dbsrgits/dbix-class-schema-loader] Not recognising primary key automatically set with uuid_generate_v4() in PostgreSQL database [rt.cpan.org #143291] (Issue #28) In-Reply-To: References: Message-ID: Thank you for your efforts. -- Reply to this email directly or view it on GitHub: https://github.com/dbsrgits/dbix-class-schema-loader/issues/28#issuecomment-1325649900 You are receiving this because you are subscribed to this thread. Message ID: -------------- next part -------------- An HTML attachment was scrubbed... URL: