From fabrizio.ge at tiscali.it Sat Jul 7 21:25:44 2018 From: fabrizio.ge at tiscali.it (Fabrizio Gennari) Date: Sat, 7 Jul 2018 23:25:44 +0200 Subject: [Dbix-class] SQL::Abstract maintainership? Message-ID: <6dbe47bd-8c83-a182-e7a3-761a8aba029e@tiscali.it> Hello, I was wondering what the maintainership status for SQL::Abstract is. The Git repository is hosted on both GitHub and http://git.shadowcat.co.uk/gitweb/gitweb.cgi?p=dbsrgits/SQL-Abstract.git;a=summary , and, on GitHub, a pull request (https://github.com/dbsrgits/sql-abstract/pull/14) has been sitting for two months without any sign of being reviewed. Regards, Fabrizio From david.cantrell at uk2group.com Tue Jul 24 10:02:34 2018 From: david.cantrell at uk2group.com (David Cantrell) Date: Tue, 24 Jul 2018 11:02:34 +0100 Subject: [Dbix-class] Are might_have relationships overly fussy? Message-ID: <9338fba4-b0b2-1fc6-b543-2b404f2da002@uk2group.com> Hello classy people! I have a result class that looks like this ... package Database::Chimera::Result::Serviceplan; use parent 'DBIx::Class::Core'; __PACKAGE__->table('serviceplan'); __PACKAGE__->add_columns( id => { data_type => 'INT', is_nullable => 0 }, ... renew_serviceplan_id => { data_type => 'INT', is_nullable => 1 }, ... ); __PACKAGE__->set_primary_key('id'); for this table ... CREATE TABLE `serviceplan` ( `id` mediumint(8) unsigned NOT NULL AUTO_INCREMENT, ... `renew_serviceplan_id` mediumint(8) unsigned DEFAULT NULL, ... PRIMARY KEY (`id`) ); In brief, a serviceplan is a description of something (a service) that we sell. They all have a duration, and when a service reaches the end of its life it can be renewed. Some renew with the same serviceplan, but some have to renew with different serviceplans. We encode this in the renew_serviceplan_id. In the case where something should renew with the same serviceplan, renew_serviceplan_id is null. I also have ... __PACKAGE__->might_have( "renew_serviceplan" => "Database::Chimera::Result::Serviceplan", { 'foreign.id' => 'self.renew_serviceplan_id' }, ); That warns like this, although as far as I can tell it returns exactly the results I need when I prefetch that relationship ... DBIx::Class::Relationship::HasOne::_validate_has_one_condition(): "might_have/has_one" must not be on columns with is_nullable set to true (Database::Chimera::Result::Serviceplan/renew_serviceplan_id). This might indicate an incorrect use of those relationship helpers instead of belongs_to. at /home/dc/Chimera/dancer/../lib/Database /Chimera/Result/Serviceplan.pm line 78 I'm a bit surprised that it says that it *must not* be like that but then works anyway. I'd expect a "must not" to be fatal. Anyway ... if I change the relationship to a 'belongs_to' with 'join_type' => 'left' it shuts up, and as far as I can tell I get exactly the same data back. ie, belongs_to with a left join appears to be *exactly the same* as a might_have, just with more typing. I wonder therefore whether 'might_have' is being too fussy here and that warning should be got rid of. -- David Cantrell David Cantrell System Architect The Hut Group Tel: Email: david.cantrell at uk2group.com For the purposes of this email, the "company" means The Hut Group Limited, a company registered in England and Wales (company number 6539496) whose registered office is at Fifth Floor, Voyager House, Chicago Avenue, Manchester Airport, M90 3DQ and/or any of its respective subsidiaries. Confidentiality Notice This e-mail is confidential and intended for the use of the named recipient only. If you are not the intended recipient please notify us by telephone immediately on +44(0)1606 811888 or return it to us by e-mail. Please then delete it from your system and note that any use, dissemination, forwarding, printing or copying is strictly prohibited. Any views or opinions are solely those of the author and do not necessarily represent those of the company. Encryptions and Viruses Please note that this e-mail and any attachments have not been encrypted. They may therefore be liable to be compromised. Please also note that it is your responsibility to scan this e-mail and any attachments for viruses. We do not, to the extent permitted by law, accept any liability (whether in contract, negligence or otherwise) for any virus infection and/or external compromise of security and/or confidentiality in relation to transmissions sent by e-mail. Monitoring Activity and use of the company's systems is monitored to secure its effective use and operation and for other lawful business purposes. Communications using these systems will also be monitored and may be recorded to secure effective use and operation and for other lawful business purposes. hgvyjuv From marco at vittorini.org Tue Jul 24 10:29:29 2018 From: marco at vittorini.org (Marco Vittorini Orgeas) Date: Tue, 24 Jul 2018 12:29:29 +0200 Subject: [Dbix-class] Are might_have relationships overly fussy? In-Reply-To: <9338fba4-b0b2-1fc6-b543-2b404f2da002@uk2group.com> References: <9338fba4-b0b2-1fc6-b543-2b404f2da002@uk2group.com> Message-ID: On 07/24/2018 12:02 PM, David Cantrell wrote: > Hello classy people! > > I have a result class that looks like this ... > > package Database::Chimera::Result::Serviceplan; > use parent 'DBIx::Class::Core'; > > __PACKAGE__->table('serviceplan'); > __PACKAGE__->add_columns( > id => { data_type => 'INT', is_nullable => 0 }, > ... > renew_serviceplan_id => { data_type => 'INT', is_nullable => 1 }, > ... > ); > __PACKAGE__->set_primary_key('id'); > > for this table ... > > CREATE TABLE `serviceplan` ( > `id` mediumint(8) unsigned NOT NULL AUTO_INCREMENT, > ... > `renew_serviceplan_id` mediumint(8) unsigned DEFAULT NULL, > ... > PRIMARY KEY (`id`) > ); > > In brief, a serviceplan is a description of something (a service) that > we sell. They all have a duration, and when a service reaches the end of > its life it can be renewed. Some renew with the same serviceplan, but > some have to renew with different serviceplans. We encode this in the > renew_serviceplan_id. In the case where something should renew with the > same serviceplan, renew_serviceplan_id is null. > > I also have ... > > __PACKAGE__->might_have( > "renew_serviceplan" => "Database::Chimera::Result::Serviceplan", > { 'foreign.id' => 'self.renew_serviceplan_id' }, > ); > > That warns like this, although as far as I can tell it returns exactly > the results I need when I prefetch that relationship ... > > DBIx::Class::Relationship::HasOne::_validate_has_one_condition(): > "might_have/has_one" must not be on columns with is_nullable set to > true (Database::Chimera::Result::Serviceplan/renew_serviceplan_id). > This might indicate an incorrect use of those relationship helpers > instead of belongs_to. at /home/dc/Chimera/dancer/../lib/Database > /Chimera/Result/Serviceplan.pm line 78 > > I'm a bit surprised that it says that it *must not* be like that but > then works anyway. I'd expect a "must not" to be fatal. Anyway ... if I > change the relationship to a 'belongs_to' with 'join_type' => 'left' it > shuts up, and as far as I can tell I get exactly the same data back. ie, > belongs_to with a left join appears to be *exactly the same* as a > might_have, just with more typing. I wonder therefore whether > 'might_have' is being too fussy here and that warning should be got > rid of. > > -- > David Cantrell > David Cantrell > System Architect > The Hut Group > > Tel: > Email: david.cantrell at uk2group.com > > For the purposes of this email, the "company" means The Hut Group > Limited, a company registered in England and Wales (company number > 6539496) whose registered office is at Fifth Floor, Voyager House, > Chicago Avenue, Manchester Airport, M90 3DQ and/or any of its > respective subsidiaries. > > Confidentiality Notice > This e-mail is confidential and intended for the use of the named > recipient only. If you are not the intended recipient please notify us > by telephone immediately on +44(0)1606 811888 or return it to us by > e-mail. Please then delete it from your system and note that any use, > dissemination, forwarding, printing or copying is strictly prohibited. > Any views or opinions are solely those of the author and do not > necessarily represent those of the company. > > Encryptions and Viruses > Please note that this e-mail and any attachments have not been > encrypted. They may therefore be liable to be compromised. Please also > note that it is your responsibility to scan this e-mail and any > attachments for viruses. We do not, to the extent permitted by law, > accept any liability (whether in contract, negligence or otherwise) > for any virus infection and/or external compromise of security and/or > confidentiality in relation to transmissions sent by e-mail. > > Monitoring > Activity and use of the company's systems is monitored to secure its > effective use and operation and for other lawful business purposes. > Communications using these systems will also be monitored and may be > recorded to secure effective use and operation and for other lawful > business purposes. > > hgvyjuv > > > _______________________________________________ > List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class > IRC: irc.perl.org#dbix-class > SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/ > Searchable Archive: > http://www.grokbase.com/group/dbix-class at lists.scsys.co.uk Have you specified a custom join condition on that relationship which is not showed on the posted code? This is straight from the docs: > Note that if you supply a condition on which to join, and the column in > the current table allows nulls (i.e., has the "is_nullable" > attribute set > to a true value), than "might_have" will warn about this because it's > naughty and you shouldn't do that. The warning will look something > like: > > "might_have/has_one" must not be on columns with is_nullable set > to true (MySchema::SomeClass/key) > > If you must be naughty, you can suppress the warning by setting > "DBIC_DONT_VALIDATE_RELS" environment variable to a true value. > Otherwise, > you probably just meant to use "DBIx::Class::Relationship/belongs_to". I have some memories of having experienced something similar in the recent past with might_have but I don't recall if I *had* actually specified a custom join condition or not. In fact I can't recall at the moment if this ended up as something on my bug queue or not: I can imagine some occasions where NULL could be a problem on custom joins, but it shouldn't be worth that warning in other cases. -- Marco From david at cantrell.org.uk Tue Jul 24 15:09:18 2018 From: david at cantrell.org.uk (David Cantrell) Date: Tue, 24 Jul 2018 16:09:18 +0100 Subject: [Dbix-class] Are might_have relationships overly fussy? In-Reply-To: References: <9338fba4-b0b2-1fc6-b543-2b404f2da002@uk2group.com> Message-ID: <20180724150918.GA29722@bytemark.barnyard.co.uk> On Tue, Jul 24, 2018 at 12:29:29PM +0200, Marco Vittorini Orgeas wrote: > Have you specified a custom join condition on that relationship which is > not showed on the posted code? This is straight from the docs: No. -- David Cantrell | semi-evolved ape-thing Disappointment: n: No results found for "priapic dwarf custard wrestling". From andrew.gregory.8 at gmail.com Tue Jul 24 16:05:09 2018 From: andrew.gregory.8 at gmail.com (Andrew Gregory) Date: Tue, 24 Jul 2018 12:05:09 -0400 Subject: [Dbix-class] Should all result classes set C3 MRO? Message-ID: <20180724160509.GA8741@b42-desktop.localdomain> Following the example in the cookbook[1], I moved components into a base result class, only to discover that cascaded deletion no longer worked. Apparently, load_components sets the MRO to C3, which DBIx::Class relies on heavily. Moving those calls out of the individual result classes caused them to revert to perl's default DFS MRO. Since InflateColumn is a subclass of DBIx::Class::Row, Row's delete method appears before CascadeActions wrapper under DFS. An example script is below. Is there any way to set the MRO for all loaded classes so that a base class, or even DBIx::Class itself, could handle this transparently, or do all classes need to individually ensure that they use C3? [1]: https://metacpan.org/pod/distribution/DBIx-Class/lib/DBIx/Class/Manual/Cookbook.pod#Move-Common-Startup-into-a-Base-Class ## broken cascade example package Test::Schema::Result; use base 'DBIx::Class::Core'; ## loads DBIx::Class::Row, putting it above ## DBIx::Class::Relationship::CascadeActions for default DFS MRO __PACKAGE__->load_components('InflateColumn::DateTime'); package Test::Schema::Result::Bar; use base 'Test::Schema::Result'; ## uncommenting either of these set C3 MRO, putting CascadeActions before Row #use mro 'c3'; #__PACKAGE__->load_components('InflateColumn::DateTime'); __PACKAGE__->table('Bar'); __PACKAGE__->add_columns( id => { data_type => 'integer', is_numeric => 1 } ); __PACKAGE__->set_primary_key('id'); __PACKAGE__->has_many( foo => 'Test::Schema::Result::Foo' => 'bar_id' ); package Test::Schema::Result::Foo; use base 'Test::Schema::Result'; __PACKAGE__->table('foo'); __PACKAGE__->add_columns( id => { data_type => 'integer', is_numeric => 1 }, bar_id => { data_type => 'integer', is_numeric => 1 }, ); __PACKAGE__->set_primary_key('id'); __PACKAGE__->belongs_to( bar => 'Test::Schema::Result::Bar' => 'id' ); package Test::Schema; use base 'DBIx::Class::Schema'; __PACKAGE__->register_class( Bar => 'Test::Schema::Result::Bar' ); __PACKAGE__->register_class( Foo => 'Test::Schema::Result::Foo' ); package main; use Test::More; my $schema = Test::Schema->connect('dbi:SQLite:dbname=:memory:'); $schema->deploy; my ( $bar_rs, $foo_rs ) = ( $schema->resultset('Bar'), $schema->resultset('Foo') ); $bar_rs->create( { id => 1 } ); $foo_rs->create( { id => 1, bar_id => 1 } ); is( $bar_rs->count, 1 ); is( $foo_rs->count, 1 ); $bar_rs->find(1)->delete; # should cascade to delete foo as well is( $bar_rs->count, 0 ); is( $foo_rs->count, 0 ); From bogus@does.not.exist.com Sat Jul 14 13:29:23 2018 From: bogus@does.not.exist.com () Date: Sat, 14 Jul 2018 13:29:23 -0000 Subject: No subject Message-ID: ass, but I'm stuck anyway... I have no admin rights on the mysql server (I didn't create the users and p= asswords myself) it is version 5.5.53 and the old_password property is set = to OFF Can someone gives me the steps to connect ? Thanks Fran=E7ois --_000_5b2ee95dbcc743a1bb2e4335649305a0svwexmb4unifrch_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi there

 

I had perl scripts that connect= happily to a mysql server for years without problem (and are still connect= ing).

I did today a second perl setup= with strawberry portable perl, have installed all the modules. When I call= the scripts and I tried to connect, I get

 

“DBI Connection failed: D= BI connect('host=3Dmysql.unifr.ch;database=3Ddokpe_i02;','dokpe_i02_adm',..= .) failed: Authentication plugin 'mysql_old_password' cannot be loaded: The= specified module could not be found.
at c:/spp/perl/vendor/lib/DBIx/Class/Storage/DBI.pm line 1517. at c:/spp/pe= rl/vendor/lib/DBIx/Class/Schema.pm line 1118.

     &= nbsp;  DBIx::Class::Schema::throw_exception(Dbc::Schema=3DHASH(0x5a57e= 34), "DBI Connection failed: DBI connect('host=3D ….ch;datab&quo= t;...) called at c:/spp/perl/vendor/lib/DBIx/Class/Storage.pm line 113̶= 1;

 

From some searches on the web, = I’m not sure this is a problem with DBIx::Class, but I’m stuck = anyway…

 

I have no admin rights on the m= ysql server (I didn’t create the users and passwords myself) it is ve= rsion 5.5.53 and the old_password property is set to OFF<= /p>

 

Can someone gives me the steps = to connect ?

 

Thanks

 

Fran=E7ois

--_000_5b2ee95dbcc743a1bb2e4335649305a0svwexmb4unifrch_-- From bogus@does.not.exist.com Sat Jul 14 13:29:23 2018 From: bogus@does.not.exist.com () Date: Sat, 14 Jul 2018 13:29:23 -0000 Subject: No subject Message-ID: ass, but I'm stuck anyway... I have no admin rights on the mysql server (I didn't create the users and p= asswords myself) it is version 5.5.53 and the old_password property is set = to OFF Can someone gives me the steps to connect ? Thanks Fran=E7ois --_000_ad06942a916a4c2abe824cbe3898d42asvwexmb4unifrch_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Well, t= here no one there  ?

&n= bsp;

I did t= his: I rename the folder in my perl perotable setup C:\spp\perl\site\lib\DB= Ix\Class to …\DBIx\_Class

By the = way it is version 0.082841

I copie= d the folder C:\strawberry\perl\site\lib\DBIx\Class to C:\spp\perl\site\lib= \DBIx

The old= er version is 0.082821

&n= bsp;

And I c= ould make the connection as usual.

&n= bsp;

So ther= e is something to do with DBIx::Class isn’t there ?=

&n= bsp;

Thanks = for any clarification

&n= bsp;

F.=

&n= bsp;

&n= bsp;

From: dbix-class-bounces at lists.scsys.co.uk <dbix-class-bounces at lists.= scsys.co.uk> On Behalf Of RAPPAZ Francois
Sent: 14 February 2019 13:21
To: dbix-class at lists.scsys.co.uk
Subject: [Dbix-class] mysql_old_password plugin

 

Hi there

 

I had perl scripts that connect= happily to a mysql server for years without problem (and are still connect= ing).

I did today a second perl setup= with strawberry portable perl, have installed all the modules. When I call= the scripts and I tried to connect, I get

 

“DBI Connection failed: D= BI connect('host=3Dmysql.unifr.ch;database=3Ddokpe_i02;','dokpe_i02_adm',..= .) failed: Authentication plugin 'mysql_old_password' cannot be loaded: The= specified module could not be found.
at c:/spp/perl/vendor/lib/DBIx/Class/Storage/DBI.pm line 1517. at c:/spp/pe= rl/vendor/lib/DBIx/Class/Schema.pm line 1118.

     &= nbsp;  DBIx::Class::Schema::throw_exception(Dbc::Schema=3DHASH(0x5a57e= 34), "DBI Connection failed: DBI connect('host=3D ….ch;datab&quo= t;...) called at c:/spp/perl/vendor/lib/DBIx/Class/Storage.pm line 113̶= 1;

 

From some searches on the web, = I’m not sure this is a problem with DBIx::Class, but I’m stuck = anyway…

 

I have no admin rights on the m= ysql server (I didn’t create the users and passwords myself) it is ve= rsion 5.5.53 and the old_password property is set to OFF<= /p>

 

Can someone gives me the steps = to connect ?

 

Thanks

 

Fran=E7ois

--_000_ad06942a916a4c2abe824cbe3898d42asvwexmb4unifrch_--