Re: [Dbix-class] Strangely does DBIx change table names from MySQL?

[Lasse Makholm]

On Fri, Mar 10, 2017 at 8:38 PM, Darren Duncan 
wrote:

> On 2017-03-10 9:12 AM, Jorge Gonzalez wrote:
>
>> DBIC by default follows the convention that table names reflect the
>> entity name
>> in singular. If It detects table names in plural It uses a Lingua::*
>> module to
>> deduce the apropriate singular name, and names the clases with It.
>>
>> In your case, the table names IS "people", but the generated class name IS
>> "Person", the singular for people.
>>
>
> Semantically this is one of those things I would argue that Entity
> Framework got (more) right and DBIC got (more) wrong.
>
> Semantically a table is a collection of rows where typically each row
> represents a singular entity, for example a single person, and a table
> represents a simple set/bag/array of those entities, and is collectively
> for example a group of 0..N people.
>
> I believe table-typed variables such as those in SQL databases should be
> named using the same naming conventions that are appropriate for arrays,
> after what the whole collection represents, such as "people", whereas
> row-typed variables would best be named for what a single row is, such as
> "person".
>
> As this simple example in SQL (like typical generated SQL) demonstrates:
>
>   select person.name, person.age from people person
>
> Here "people" is the name of the table-typed SQL variable, and "person" is
> the name of the SQL range variable declared in the "select" that represents
> each individual row in turn.
>
> This is a loose Perl analogy:
>
>   for my $person ($db->people) { print $person->name, $person->age }
>

That's sort of what DBIC does already:

my $people = $db->resultset('Person')->search(...);
foreach my $person ($people->all) { ... }

And so, DBIC would ideally name any classes/objects/variables representing
> a single person as Person while any representing a collection would be
> People, which is the behavior that "code first" Entity Framework defaults
> to.
>

The DBIC result source is named Person and each result (row) object is a
Person. You should (in my opinion) read $db->resultset('Person') as
"collection of objects of type Person".

DBIC is nice in that way; it doesn't force you to remember when something
is plural or singular - it's always singular. If you want to name your
resultset $people, you are perfectly free to do so.


>
> -- Darren Duncan
>
>
> ___
> List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class
> IRC: irc.perl.org#dbix-class
> SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/
> Searchable Archive: http://www.grokbase.com/group/
> dbix-class@lists.scsys.co.uk
>
___
List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class
IRC: irc.perl.org#dbix-class
SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/
Searchable Archive: http://www.grokbase.com/group/dbix-class@lists.scsys.co.uk

Re: [Dbix-class] Traffic pattern changes ahead

[Lasse Makholm]

I think warrants a huge +1! :-)

/L

On Fri, Oct 7, 2016 at 10:34 PM, Darren Duncan  wrote:
> On 2016-10-07 10:08 AM, Peter Rabbitson wrote:
> 
>>
>> master (dc7d89911b) itself is *in a fully releasable state*. It passes its
>> extensive CI checks. It has also been tested against downstream
>> dependencies
>> extensively as indicated in the commit message of dc7d89911b. With that
>> being
>> said - it is not in a state of completion I would have shipped it myself
>> (what
>> is mainly bugging me are the missing warnings).
>
>
> Thanks a lot for this message!  My primary concern has been addressed by it.
>
> While you didn't yet implement everything you wanted to, the actual work
> that you performed is committed and you consider the codebase to be
> release-ready as is.
>
> Even if you don't do anything else on the codebase, you have then left a
> strong legacy and people will benefit greatly from all the work you did so
> far, which is not wasted.  Also, you did finish many of your checklist items
> 100% even if not all of them.
>
> That being said, I say more power to you where you want to write/commit the
> other pieces that you would prefer to ship, particularly the warnings.
>
> Thanks again for all your work over the years, DBIC users are better for it.
>
> -- Darren Duncan
>
>
>
> ___
> List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class
> IRC: irc.perl.org#dbix-class
> SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/
> Searchable Archive:
> http://www.grokbase.com/group/dbix-class@lists.scsys.co.uk

___
List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class
IRC: irc.perl.org#dbix-class
SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/
Searchable Archive: http://www.grokbase.com/group/dbix-class@lists.scsys.co.uk

Re: [Dbix-class] IMPORTANT: A discussion of DBIC governance and future development

[Lasse Makholm]

On Wed, Oct 5, 2016 at 12:23 PM, Leo Lapworth  wrote:
>
> Hi,
>
> On 5 October 2016 at 10:44, Peter Rabbitson  wrote:
> > On 10/05/2016 08:50 AM, Karen Etheridge wrote:
> >>>
> >>> It is now much harder to advance either of these points.
> >>
> >> Why?
> >>
> > Because now that you causally dropped an insinuation that a part of the work
> > I put into DBIC itself was performed for material gain
>
> I can't say I considered this for a moment when reading Karen's comment.
>
> I would hope that anyone doing such great work as you did in an Open Source
> project SHOULD have the opportunity to make some money by supporting
> the companies that use it, but I only consider this now you mention
> material gain.
>
> I read Karen's comment as a validation of how important, not just to
> casual users
> but to businesses the work you have or are doing. This is a sign of a 
> successful
> project, not an issue in my mind.

I totally agree. Anyone who knows enough about DBIC (or open source
software in general for that matter) to have read this thread, will
know that your (Peter's) involvement in this project is infinitely
more than just a cash-grab. Frankly, to me at least, that notion is
ludicrous.

I too hail from a critical production environment relying on DBIC at
its core. We've come to rely (and probably take for granted) the
stability of DBIC and thus the expertise and diligence of its
maintainer(s).

However, I too worry about DBIC becoming a one-man project. The idea
of a core-team kind of setup, focused on stability sounds sensible to
me. And I have no good reason to think it wouldn't work.

/Lasse

>
> Leo
>
> ___
> List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class
> IRC: irc.perl.org#dbix-class
> SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/
> Searchable Archive: http://www.grokbase.com/group/dbix-class@lists.scsys.co.uk

___
List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class
IRC: irc.perl.org#dbix-class
SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/
Searchable Archive: http://www.grokbase.com/group/dbix-class@lists.scsys.co.uk

Re: [Dbix-class] updated release has broken my code

[Lasse Makholm]

On Wed, Jan 20, 2016 at 4:32 PM, Dave Howorth 
wrote:

> I have various applications that use DBIx::Class. I just moved one of
> them, which has been running OK for quite a while, to a new machine and
> that meant it got a new environment, including an updated DBIx::Class. It
> no longer runs, and it would help me to try to understand what is broken in
> my own code if I could understand how the DBIC code works and why it was
> changed. If anybody could give me any pointers, I'd be grateful.
>
> My code is dying with the error message:
>
> DBIx::Class::Row::store_column(): No such column '_type' on
> TDB::Schema::Result::Node
>
> This appears to be caused by a change in the code in DBIx::Class::Row in
> store_column() in particular where
>
>   $self->throw_exception( "No such column '${column}'" )
> unless exists $self->{_column_data}{$column} ||
> $self->has_column($column);
>
> has been replaced by
>
>   $self->throw_exception( "No such column '${column}' on " . ref $self )
> unless exists $self->{_column_data}{$column} ||
> $self->result_source->has_column($column);
>
> If I put back the original code there, my application appears to work.
>
> Now my TDB::Schema::Result::Node contains some gnarly code that it will
> take me some time to regain familiarity with, and I think it would help me
> if I understood why that change had been made in DBIx::Class::Row so I
> might get some idea of what I need to change in my own code.
>
> If anybody can point me to the change or provide any explanation, I'd
> appreciate it.
>

https://github.com/dbsrgits/dbix-class/commit/4006691d207a6c257012c4b9a07d674b211349b0

Without knowing what I'm talking about, this would seem to only matter if
you do something funky like dynamically re-blessing result objects...

Does TDB::Schema::Result::Node and the underlying table actually have a
_type column?

/L


>
> Cheers, Dave
>
> PS The old version says it is  '0.08200' and the new is '0.082820'.
>
> ___
> List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class
> IRC: irc.perl.org#dbix-class
> SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/
> Searchable Archive:
> http://www.grokbase.com/group/dbix-class@lists.scsys.co.uk
>
___
List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class
IRC: irc.perl.org#dbix-class
SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/
Searchable Archive: http://www.grokbase.com/group/dbix-class@lists.scsys.co.uk

Re: [Dbix-class] dbicdump takes very long

[Lasse Makholm]

DBIx::Class::Schema::Loader does *a lot* of queries on your DB to
introspect it, so runtime is heavily dependant on latency to your DB
server

Try tracing the queries:

DBI_TRACE=1 dbicdump ...

That should give you an idea of why it's so slow... In my experience, most
of the time is spent making queries, as opposed to actually generating your
result classes

/L

On Fri, Jul 10, 2015 at 1:19 PM, thilo.fes...@googlemail.com 
thilo.fes...@gmail.com wrote:

 Hello,

 I'm just updating my model classes using dbicdump [
 https://metacpan.org/pod/dbicdump] as I usually do. The output looks good
 so far - there are no errors I could refer to.
 But the script is painfully slow. I have been waiting for five hours now
 and the script did not finish yet. My schema has around 120 tables but as
 far as I remember, it never took so long before.

 The config file looks like that ...

 loader_options
 components  InflateColumn::DateTime
 components  Helper::Row::ToJSON
 debug   1
 db_schema   MYSCHEMA
 dump_directory  ./lib
 naming
 ALL v8
 force_ascii 1
 /naming
 overwrite_modifications 1
 skip_load_external  1
 use_moose   1
 /loader_options

 .. without connect string.

 I am connected to an Oracle Database 12c (Release 12.1.0.2.0, 64bit). The
 connection is stable and Oracle is processing and delivering results pretty
 fast for usual queries.

 My machines load average: 0,30, 0,41, 0,36

 Where is the bottleneck? Did anybody observe this or a similar behaviour
 before?

 Regards
 Thilo

 ___
 List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class
 IRC: irc.perl.org#dbix-class
 SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/
 Searchable Archive:
 http://www.grokbase.com/group/dbix-class@lists.scsys.co.uk

___
List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class
IRC: irc.perl.org#dbix-class
SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/
Searchable Archive: http://www.grokbase.com/group/dbix-class@lists.scsys.co.uk

Re: [Dbix-class] Inflated DateTime column not updated on $row-update({ ts_column = undef })

[Lasse Makholm]

On Sat, May 23, 2015 at 9:35 AM, Peter Rabbitson rabbit+d...@rabbit.us
wrote:

 On 05/22/2015 09:57 PM, Lasse Makholm wrote:

 It seems DBIx::Class::InflateColumn::DateTime does not update the
 inflated column value on: $row-update({ ts_column = undef })


 That is a bug, not sure how it went overlooked for so long :( It is
 present as far back as 0.08112 (2009), likely earlier.


Yeah, it seems remarkable that I'm the first to stumble across this. On the
other hand, I only found it because I was trying to get 100% condition
coverage on something and was updating a row through all permutations of a
couple of conditions.

I guess, generally, updating a timestamp column to null after it has had a
value, is just not a very common thing to do.


 Because of the nontrivial possibility of negative impact of changing
 something so fundamental, I have to think this through before going forward.


Yeah, I don't really see a pretty way around this without risking a lot of
random breakage.

In the meantime an easy workaround for you is to add the following to a
 base result class (this is a hack, a real fix will materialize later):

   sub store_column {
 delete $_[0]-{_inflated_column}{$_[1]};
 shift-next::method(@_);
   }

 Sorry for not being able to offer anything better at the moment :(


No worries. As far as workarounds/hacks go, this one is pretty decent. I've
seen and done a lot worse... :-)

Thanks for confirming this.

/L



 ___
 List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class
 IRC: irc.perl.org#dbix-class
 SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/
 Searchable Archive:
 http://www.grokbase.com/group/dbix-class@lists.scsys.co.uk

___
List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class
IRC: irc.perl.org#dbix-class
SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/
Searchable Archive: http://www.grokbase.com/group/dbix-class@lists.scsys.co.uk

Re: [Dbix-class] Is it possible to use dumb result classes with DBIx::Class?

[Lasse Makholm]

Hah! You're right! It does work.

It was just me failing to realize that the errors were actually thrown at
load time, not inflate time. The problem is putting a dumb under
MyApp::Schema::Result:: because DBIx::Class will try to load and initialize
it as a normal result class during DBIx::Class::Schema-load_namespaces().

Putting the dumb result class outside the MyApp::Schema::Result:: namespace
works just fine.

Thanks for your help both of you.

/L

On Thu, Apr 9, 2015 at 5:34 PM, Dmitry L. dim0...@gmail.com wrote:

 Strange. Your example just works for me.
 I tried it with DBIC example ( DBIx::Class::Manual::Example ) without
 any changes, just copy-paste.

 And yes, I use the latest DBIC.

 On 9 April 2015 at 16:58, Lasse Makholm la...@unity3d.com wrote:
  I'm using DBIx::Class::ResultClass::HashRefInflator in some places where
  full row object inflation is too slow. That's fine.
 
  What I'd really like to do though, is bless the resulting hashrefs into a
  light weight result class that provides a few convenience methods but
  knows little to nothing about DBIx::Class.
 
  Trying something like:
 
  my $rs = $schema-resultset('MyTable')-search(...);
  $rs-result_class('MyApp::Schema::DumbResult::MyTable');
  while (my $thingy = $rs-next) {
 
  # do, do, do
 
  }
 
 
  with something like:
 
  package MyApp::Schema::DumbResult::MyTable;
 
  use strict;
  use warnings;
 
  use DBIx::Class::ResultClass::HashRefInflator;
 
  sub inflate_result
  {
  my $class = shift;
  my $result =
 DBIx::Class::ResultClass::HashRefInflator-inflate_result(@_);
  return bless $result, $class;
  }
 
  sub TO_JSON
  {
  my $self = shift;
  return { %$self };
  }
 
  1;
 
 
  ...breaks for a variety of reasons it seems, because DBIx::Class wants
 to do
  things like setting a result source instance on the result object, etc...
 
  Is there an (easy) make this work? Or is it just in general a horrible
 idea?
 
  Of course I can just do:
 
  $rs-result_class('DBIx::Class::ResultClass::HashRefInflator');
  my @stuff = map { bless $_, MyApp::Schema::DumbResult::MyTable }
 $rs-all;
 
  ...but the other way is more convenient...
 
  Or is it more sane to subclass the ResultSet and override first(), all()
 and
  next() to set the result_class and bless the resulting hashrefs?
 
  Any input appreciated?
 
  /L
 
 
 
  ___
  List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class
  IRC: irc.perl.org#dbix-class
  SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/
  Searchable Archive:
  http://www.grokbase.com/group/dbix-class@lists.scsys.co.uk



 --
 //wbr, Dmitry L.

 ___
 List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class
 IRC: irc.perl.org#dbix-class
 SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/
 Searchable Archive:
 http://www.grokbase.com/group/dbix-class@lists.scsys.co.uk

___
List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class
IRC: irc.perl.org#dbix-class
SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/
Searchable Archive: http://www.grokbase.com/group/dbix-class@lists.scsys.co.uk

[Dbix-class] Is it possible to use dumb result classes with DBIx::Class?

[Lasse Makholm]

I'm using DBIx::Class::ResultClass::HashRefInflator in some places where
full row object inflation is too slow. That's fine.

What I'd really like to do though, is bless the resulting hashrefs into a
light weight result class that provides a few convenience methods but
knows little to nothing about DBIx::Class.

Trying something like:

my $rs = $schema-resultset('MyTable')-search(...);
$rs-result_class('MyApp::Schema::DumbResult::MyTable');
while (my $thingy = $rs-next) {

# do, do, do

}


with something like:

package MyApp::Schema::DumbResult::MyTable;

use strict;
use warnings;

use DBIx::Class::ResultClass::HashRefInflator;

sub inflate_result
{
my $class = shift;
my $result = DBIx::Class::ResultClass::HashRefInflator-inflate_result(@_);
return bless $result, $class;
}

sub TO_JSON
{
my $self = shift;
return { %$self };
}

1;


...breaks for a variety of reasons it seems, because DBIx::Class wants to
do things like setting a result source instance on the result object, etc...

Is there an (easy) make this work? Or is it just in general a horrible idea?

Of course I can just do:

$rs-result_class('DBIx::Class::ResultClass::HashRefInflator');
my @stuff = map { bless $_, MyApp::Schema::DumbResult::MyTable } $rs-all;

...but the other way is more convenient...

Or is it more sane to subclass the ResultSet and override first(), all()
and next() to set the result_class and bless the resulting hashrefs?

Any input appreciated?

/L
___
List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class
IRC: irc.perl.org#dbix-class
SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/
Searchable Archive: http://www.grokbase.com/group/dbix-class@lists.scsys.co.uk

Re: [Dbix-class] Getting numeric columns as numeric values

[Lasse Makholm]

On Wed, Feb 25, 2015 at 10:59 PM, Darren Duncan dar...@darrenduncan.net
wrote:

 Augustus, what is the problem with DBIC stringifying numeric values?  That
 ensures full precision and in particular when you want to use them as
 numbers you can just do so, Perl does that automatically. -- Darren Duncan


One example of it being a problem is when converting row objects to JSON.
Javascripts === operator, for example, evaluates to false for for 42 ===
42.

/L




 On 2015-02-25 1:15 PM, Augustus Saunders wrote:

 For reasons unknown to us, DBIx is stringifying numeric values somewhere
 along the way. In order to ensure they come out numeric, we made this small
 patch:

 --- a/lib/perl5/DBIx/Class/Row.pm
 +++ b/lib/perl5/DBIx/Class/Row.pm
 @@ -661,10 +661,15 @@ To retrieve all loaded column values as a hash, use
 L/get_columns.
   sub get_column {
 my ($self, $column) = @_;
 $self-throw_exception( Can't fetch data as class method ) unless
 ref $self;
 -  return $self-{_column_data}{$column} if exists
 $self-{_column_data}{$column};
 +  if (exists $self-{_column_data}{$column}) {
 +return 0 + $self-{_column_data}{$column} if
 $self-_is_column_numeric($column);
 +return $self-{_column_data}{$column};
 +  }
 if (exists $self-{_inflated_column}{$column}) {
 -return $self-store_column($column,
 +my $ret = $self-store_column($column,
 $self-_deflated_column($column, $self-{_inflated_column}{$
 column}));
 +return 0 + $ret if $self-_is_column_numeric($column);
 +return $ret;
 }
 $self-throw_exception( No such column '${column}' ) unless
 $self-has_column($column);
 return undef;

 If there's a better way to do this, or some way to prevent DBIx from
 stringifying the values in the first place, that would be nice to know too.
 Thanks-

 Augustus



 ___
 List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class
 IRC: irc.perl.org#dbix-class
 SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/
 Searchable Archive: http://www.grokbase.com/group/
 dbix-class@lists.scsys.co.uk

___
List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class
IRC: irc.perl.org#dbix-class
SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/
Searchable Archive: http://www.grokbase.com/group/dbix-class@lists.scsys.co.uk

Re: [Dbix-class] Dynamic/Flexible DBIC views

[Lasse Makholm]

On Fri, Nov 28, 2014 at 4:04 PM, Christian Lackas lac...@lackas.net wrote:

 * Darius Jokilehto dariusjokile...@yahoo.co.uk [141122 07:43]:

 Dear Darius,

 thanks for your input (David as well).

  You can implement this by passing an identity instead of a value, i.e.
 me.customer_id = me.customer_id. So either pass (untested):
   { -ident = 'me.customer_id' }
  or if that doesn't work a scalar ref:
   \'me.customer_id'
  Granted, it's still not pretty, but it should work.

 unfortunately, passing in literal parameters or even references to raw
 SQL does not work with bind values. Which does make sense since the
 whole point of bind values is that they are safely escaped values and
 avoid having to check the input yourself.

 Unfortunately, bind values seem the only way one can communicate with a
 virtual views, which makes them a lot less flexible than they could be.

 Will try to create views on the fly now, however, have not yet found out
 how to do this (that is not having the Schema load them automatically
 from pm files)...


Interesting problem... As it turns out, adding a result source dynamically
is not that difficult. The following works for me:

use feature qw(say);
use Data::Dumper;
use Scalar::Util qw(blessed);

use Class::MOP;

my $schema = MyApp::Schema-connect(...);

my $meta_class = Class::MOP::Class-create_anon_class(
superclasses = [ qw(DBIx::Class::Core) ],
);

my $class = $meta_class-name;
(my $table = $class) =~ s/::/_/g;

$class-load_components(InflateColumn::DateTime);
$class-table_class('DBIx::Class::ResultSource::View');
$class-table($table);
$class-result_source_instance-is_virtual(1);
$class-result_source_instance-view_definition(q{
SELECT 42 as number, foo as string, NOW() as date
});

$class-add_columns(
  number =  { data_type = bigint, default_value = 0, is_nullable = 0
},
  string =  { data_type = varchar, is_nullable = 1, size = 255 },
  date   =  { data_type = timestamp, datetime_undef_if_invalid = 1,
timezone = UTC },
);

$schema-register_source(Foo = $class-result_source_instance);

my $row = $schema-resultset('Foo')-first;

say blessed($row);
say blessed($row-date);
say Dumper({ $row-get_columns });


Creating a virtual view factory should mostly be a SMOP. Additionally,
with a bit of introspection, you could copy column and relationship
definitions from your normal result sources where it makes sense. This
would allow you to do something a la:

my $view = $schema-create_virtual_view(
ArtistAlbumCountView = q{ SELECT artist_id, COUNT(*) AS album_count FROM
album GROUP BY artist_id },
artist_id = 'artist.id', # copy column + rel info
album_count = { data_type = 'bigint', ... },
);


Which would presumably allow you to traverse relations as usual:

my $artist = $view-search-first-artist;


Some things to look out for would be leaking memory if you create a large
number of views. DBIx::Class implements unregister_schema() but I don't see
any supported way of destroying the result source instance.

Also, I'm not sure to which degree you can destroy a package/class and
avoid leaking memory over time. Things like having a pool of reusable class
names or hashing the SQL query and putting it in the class name to avoid
duplicating views might help here.

On the other hand if your workers only serve a limited number of requests
before being restarted, this may never be a real problem.

Good luck! :-)

/L




 Christian

 --
 Dr. Christian Lackas, Managing Partner
 inviCRO, LLC -- In Imaging Yours
 http://www.invicro.com/  http://www.spect-ct.com/

 ___
 List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class
 IRC: irc.perl.org#dbix-class
 SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/
 Searchable Archive:
 http://www.grokbase.com/group/dbix-class@lists.scsys.co.uk

___
List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class
IRC: irc.perl.org#dbix-class
SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/
Searchable Archive: http://www.grokbase.com/group/dbix-class@lists.scsys.co.uk

Re: [Dbix-class] update and join

[Lasse Makholm]

On Tue, Nov 18, 2014 at 12:50 PM, Peter Rabbitson rabbit+d...@rabbit.us
wrote:

 On 11/18/2014 12:36 PM, RAPPAZ Francois wrote:

 Thanks for replying !

 So it's a feature, not a bug ?


 It's neither, it has to do with design.

  In mysql, I can execute
 update `ddrefs` inner join `ddusers` using (iduser) set id_credit = 22
 WHERE ddrefs.iduser = 3


 A similar (though *not* identical) effect can be achieved by operating on
 a ResultSet (not Result). Given your original example, the above would look
 something like:

 $s-resultset('Ddref')-search(
   { 'RefUser.iduser' = 3 },
   { join = 'RefUser' }
 )-update({ id_credit = 22 });

 Again - you need to internalize the difference between the Result and
 ResultSet concepts, they are not interchangeable (if anything - they are
 orthogonal).


What really made it click for me was realizing that I should think of a
ResultSet, not primarily as a collection of rows, but rather as an SQL
query under construction (that might eventually get executed by calling
-first, -next, -all, etc...).

In reality, of course, ResultSets behave as both, but the part about it
being a query-in-the-making is a subtle yet profound aspect that enables
all sorts of interesting design patterns.

It took me too long to realize this when I started out with DBIC - probably
because our code base made almost no use of it...

/L



 ___
 List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class
 IRC: irc.perl.org#dbix-class
 SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/
 Searchable Archive: http://www.grokbase.com/group/
 dbix-class@lists.scsys.co.uk

___
List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class
IRC: irc.perl.org#dbix-class
SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/
Searchable Archive: http://www.grokbase.com/group/dbix-class@lists.scsys.co.uk

Re: [Dbix-class] Proper way to suppress die from DBIx::Class

[Lasse Makholm]

Additionally, custom resultset classes should be found and loaded
automagically if you use_namespace = 1 in the loader options (the default
these days, I believe)...

See also:
http://search.cpan.org/~ribasushi/DBIx-Class-0.082801/lib/DBIx/Class/Schema.pm#load_namespaces

/L

On Fri, Oct 17, 2014 at 3:06 PM, Sean Quinlan spq.e...@gmail.com wrote:

 Aha! Thank you!

 On Thu, Oct 16, 2014 at 9:00 PM, Charlie Garrison garri...@zeta.org.au
 wrote:

 Good morning,

 On 16/10/14 at 2:32 PM -0400, Sean Quinlan spq.e...@gmail.com wrote:

 I did not. I knew I could do that for every specific resultset (lots of
 examples of that). How do I override the base class for all resultsets in
 one place. Just create my own class with:
 use base 'DBIx::Class::Core';

 Yes.

 And change all the Result classes to base from mine? But that then
 breaks dbicdump, which I would also like to avoid. Or is there a better
 way
 to do it that I missed in the docs?

 Check loader_options for DBIx::Class::Schema::Loader (which dbicdump
 uses), eg:

   result_base_class = 'YourResultBase'


 Charlie

 --
Charlie Garrison  garri...@zeta.org.au
github.com/cngarrison   metacpan.org/author/CNG

 O ascii ribbon campaign - stop html mail - www.asciiribbon.org
 http://www.ietf.org/rfc/rfc1855.txt


 ___
 List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class
 IRC: irc.perl.org#dbix-class
 SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/
 Searchable Archive:
 http://www.grokbase.com/group/dbix-class@lists.scsys.co.uk



 ___
 List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class
 IRC: irc.perl.org#dbix-class
 SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/
 Searchable Archive:
 http://www.grokbase.com/group/dbix-class@lists.scsys.co.uk

___
List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class
IRC: irc.perl.org#dbix-class
SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/
Searchable Archive: http://www.grokbase.com/group/dbix-class@lists.scsys.co.uk

Re: [Dbix-class] Proper way to suppress die from DBIx::Class

[Lasse Makholm]

On Wed, Oct 15, 2014 at 7:11 PM, Sean Quinlan spq.e...@gmail.com wrote:

 Thanks!

 I would have prefered to _not_ have to set unsafe, as it would be great if
 DBIC continued to handle exceptions internally as always, but just didn't
 pass the exception out after catching and handling it internally.

 And I appreciate the 'architecturally unsound' warning, and would agree
 in general. The only reason we're doing it this way is that we already have
 exception handling built in to the application. The idea here is not to
 just skip handling exceptions, but rather automate propagating exceptions
 up to the application level, without having to hand-wrap all calls in eval.
 So if handle_error in DBI calls our applications add_error() (_without_
 blocking or altering DBIC's), then the die on call is redundant, as the
 apps existing error handling will pick it up.


I'm really struggling to understand this reasoning, so forgive me if I come
across as telling you that you're doing it all wrong...

Surely exceptions are always propagated up through the call stack to the
nearest catch block and since DBIC does not catch exceptions for you, you
are free to put a try/catch pair as high or as low in the call stack as you
want. The whole point of structured exception handling is to let you put
error handling where you want it instead of around every call that might
possibly go wrong, no?

A try/catch pair in your dispatcher or entry point to your response handler
should be a trivial thing to implement and would take care of meaningful
responses in case of exceptions. Assuming no other try/catch pairs in the
code path for a given request, that would still, of course, abort execution
after the first error. But you want it to continue, right? Is that the crux
of the matter?

I guess you have your reasons wanting to do that but I can think of any
number of reasons (ranging from simply returning incorrect data to deleting
the wrong data or worse) why this approach is dangerous. And I guess that's
what Peter means by architecturally unsound...

Given a chunk of code that does multiple inserts/updates - do you really
want it to just blindly continue, even after something has gone wrong?

I'm curious about what sort of application would want that kind of
unsafe-by-default behaviour...


 Actually, if you wanted to encourage die or handle as an explicit decision
 and still discourage not handling it at all, perhaps a new optional
 argument to connect to provide a callback for external error handling,
 which when provided sets DBIC to not propagate fatal errors to the
 application? exception_action seemed to come close, but was triggered too
 often and did not suppress the die.


You probably know this already but in case you don't: With DBIC it's a
relatively trivial thing to create your own base class for all resultsets
and all result classes in your schema. In those two classes, overriding
insert(), update() and a handful of other methods would probably get you
what you want. It's of course more work than just flipping a switch in
DBIC, but it's a lot less work than changing every place you call into
DBIC. E.g. assuming a property on your schema that knows what to do with
exceptions, something like:

sub update
{
my $self = shift;
return try {
$self-next::method(@_);
} catch {
$self-result_source-schema-some_context_thingy-add_error($_);
};
}

/L

Please feel free to email me directly if there is anything I can do to help
 or questions I can answer. I'd also of course be happy to test any updates.

 -Cheers,
 Sean

 On Wed, Oct 15, 2014 at 12:01 PM, Peter Rabbitson rabbit+d...@rabbit.us
 wrote:

 On 10/15/2014 04:55 PM, Sean Quinlan wrote:

 The end result I want is to not have to wrap every update / insert / etc
 with an eval.

 I have no problem if DBIC internals use exception-based control
 internally. I just want to optionally have it not bubble up to the level
 of my application. It would be far more elegant if I could have DBIC
 play nicely with our applications exception handling, rather than have
 to insulate every usage manually.


 This is a reasonable (albeit architecturally unsound) request. If the
 'unsafe' handling is requested everything not happening in a transaction
 should indeed not result in exceptions.

 In order to go forward with this I will need a modest set of lives_ok
 checks for various operations. The actual implementation will be more
 involved and will likely be carried out by me or another core contrib. For
 a concise test example, take a look at
 https://github.com/dbsrgits/dbix-class/blob/current/for_
 cpan_index/t/schema/anon.t

 Let me know if you have any further questions

 Cheers!


 ___
 List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class
 IRC: irc.perl.org#dbix-class
 SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/
 Searchable Archive: http://www.grokbase.com/group/
 dbix-class@lists.scsys.co.uk



 

Re: [Dbix-class] Proper way to suppress die from DBIx::Class

[Lasse Makholm]

On Wed, Oct 15, 2014 at 7:11 PM, Sean Quinlan spq.e...@gmail.com wrote:

 Thanks!

 I would have prefered to _not_ have to set unsafe, as it would be great if
 DBIC continued to handle exceptions internally as always, but just didn't
 pass the exception out after catching and handling it internally.

 And I appreciate the 'architecturally unsound' warning, and would agree
 in general. The only reason we're doing it this way is that we already have
 exception handling built in to the application. The idea here is not to
 just skip handling exceptions, but rather automate propagating exceptions
 up to the application level, without having to hand-wrap all calls in eval.
 So if handle_error in DBI calls our applications add_error() (_without_
 blocking or altering DBIC's), then the die on call is redundant, as the
 apps existing error handling will pick it up.

 Actually, if you wanted to encourage die or handle as an explicit decision
 and still discourage not handling it at all, perhaps a new optional
 argument to connect to provide a callback for external error handling,
 which when provided sets DBIC to not propagate fatal errors to the
 application? exception_action seemed to come close, but was triggered too
 often and did not suppress the die.


Thinking about this, something like an internal_exception_action and an
external_exception_action might be a useful distinction. The current
behaviour of (internal) exception_action is useful because it allows us to
capture the full amount of information about the origin of errors (stack,
args, etc...) and use custom exception classes but is, as Sean points out,
ill-suited for making errors non-fatal.

An external_exception_behaviour, on the other hand, would be useful for
facilitating application defined error behaviour. Especially if the return
value of such a hook would propagate back out to the caller of the failed
DBIC method. Think:

In schema class:

__PACKAGE__-external_exception_action(sub { return
MyApp::DBICError-new(@_) });

Elsewhere:

my $rs = $rsrc-search();
my @results = $rs-isa('MyApp::DBICError') ? () : $rs-all;

/L

Please feel free to email me directly if there is anything I can do to help
 or questions I can answer. I'd also of course be happy to test any updates.

 -Cheers,
 Sean

 On Wed, Oct 15, 2014 at 12:01 PM, Peter Rabbitson rabbit+d...@rabbit.us
 wrote:

 On 10/15/2014 04:55 PM, Sean Quinlan wrote:

 The end result I want is to not have to wrap every update / insert / etc
 with an eval.

 I have no problem if DBIC internals use exception-based control
 internally. I just want to optionally have it not bubble up to the level
 of my application. It would be far more elegant if I could have DBIC
 play nicely with our applications exception handling, rather than have
 to insulate every usage manually.


 This is a reasonable (albeit architecturally unsound) request. If the
 'unsafe' handling is requested everything not happening in a transaction
 should indeed not result in exceptions.

 In order to go forward with this I will need a modest set of lives_ok
 checks for various operations. The actual implementation will be more
 involved and will likely be carried out by me or another core contrib. For
 a concise test example, take a look at
 https://github.com/dbsrgits/dbix-class/blob/current/for_
 cpan_index/t/schema/anon.t

 Let me know if you have any further questions

 Cheers!


 ___
 List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class
 IRC: irc.perl.org#dbix-class
 SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/
 Searchable Archive: http://www.grokbase.com/group/
 dbix-class@lists.scsys.co.uk



 ___
 List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class
 IRC: irc.perl.org#dbix-class
 SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/
 Searchable Archive:
 http://www.grokbase.com/group/dbix-class@lists.scsys.co.uk

___
List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class
IRC: irc.perl.org#dbix-class
SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/
Searchable Archive: http://www.grokbase.com/group/dbix-class@lists.scsys.co.uk

Re: [Dbix-class] $rs-create() with no column values bombs on Oracle

[Lasse Makholm]

On Fri, Sep 12, 2014 at 6:25 AM, Peter Rabbitson rabbit+d...@rabbit.us
wrote:

 On 09/11/2014 11:39 PM, Lasse Makholm wrote:



 On Thu, Sep 11, 2014 at 7:58 PM, Peter Rabbitson rabbit+d...@rabbit.us
 mailto:rabbit+d...@rabbit.us wrote:

 On 09/11/2014 05:48 PM, Lasse Makholm wrote:

 Hi,

 We're porting a DBIx::Class application from MySQL to Oracle,
 containing
 some insert statements with no column specifications by way of
 $rs-create({}). This doesn't seem to work on Oracle.

 DBIx::Class::SQLMaker generates INSERT INTO table DEFAULT VALUES
 RETURNING id INTO ? which, as far as I can figure is not valid
 syntax
 on Oracle. Neither the is the other common variant for such
 statements;
 INSERT INTO table () VALUES ().


 This is clearly a bug that we've never tested for previously. Can
 you please confirm that the following works on your Oracle RDBMS
 (yes, the first ()pair is gone):

 INSERT INTO $tablename VALUES(DEFAULT);


 That only works for a table with only one column. For more, you'd need
 to repeat DEFAULT for each column. Otherwise you get: SQL Error:
 ORA-00947: not enough values.


 I see.


 I wonder how/if an explicit DEFAULT interacts with the typical scenario
 of having a before insert trigger pulling IDs from a sequence to
 implement auto increment columns...

 I guess, in a sense, that question boils down whether there's any
 difference between:

 INSERT INTO t (a, b) VALUES (DEFAULT, 42)

 and:

 INSERT INTO t (b) VALUES (42)

 In any case, I don't know the answer but I suspect we have some resident
 Oracle experts who do... I'll discuss it with them and report back...


 Yes please do. What we are looking for basically is the most universal
 statement we could come up with. Putting it in is just a SMOP after that.


So, to the best of my knowledge and that of those I've talked to, there is
no way insert a row in Oracle without listing at least one column.

That leaves picking an arbitrary list of columns and supplying the DEFAULT
keyword as value.

I guess that leaves the question of how many and which columns to specify
in the insert statement. Choosing one arbitrary column seems weird but
including all columns seems overly redundant/wasteful. I'm not sure which
solution is less ugly...

Thoughts?

/L

Cheers


 ___
 List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class
 IRC: irc.perl.org#dbix-class
 SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/
 Searchable Archive: http://www.grokbase.com/group/
 dbix-class@lists.scsys.co.uk

___
List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class
IRC: irc.perl.org#dbix-class
SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/
Searchable Archive: http://www.grokbase.com/group/dbix-class@lists.scsys.co.uk

[Dbix-class] $rs-create() with no column values bombs on Oracle

[Lasse Makholm]

Hi,

We're porting a DBIx::Class application from MySQL to Oracle, containing
some insert statements with no column specifications by way of
$rs-create({}). This doesn't seem to work on Oracle.

DBIx::Class::SQLMaker generates INSERT INTO table DEFAULT VALUES RETURNING
id INTO ? which, as far as I can figure is not valid syntax on Oracle.
Neither the is the other common variant for such statements; INSERT INTO
table () VALUES ().

A workaround might be to pick an arbitrary column (having a default value)
and doing $rs-create({ column = \'DEFAULT' }), yielding INSERT INTO
table (some_column) VALUES (DEFAULT) RETURNING id INTO ? but that seems
hackish and hard to turn into a generic solution. I'm also not familiar
enough with Oracle to know if there are any side-effects from this.

Is this simply a known limitation on Oracle and something I'll have to
handle in my application or am I missing something...?

In any case, it seems like the least I should get is an error from
DBIx::Class instead of an invalid SQL statement.

I'm seeing this with DBIx::Class v0.08270-22-g83d2991 (current master)
against an Oracle 11g XE server.

Any input is appreciated.

Thanks
/Lasse
___
List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class
IRC: irc.perl.org#dbix-class
SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/
Searchable Archive: http://www.grokbase.com/group/dbix-class@lists.scsys.co.uk

Re: [Dbix-class] $rs-create() with no column values bombs on Oracle

[Lasse Makholm]

On Thu, Sep 11, 2014 at 7:58 PM, Peter Rabbitson rabbit+d...@rabbit.us
wrote:

 On 09/11/2014 05:48 PM, Lasse Makholm wrote:

 Hi,

 We're porting a DBIx::Class application from MySQL to Oracle, containing
 some insert statements with no column specifications by way of
 $rs-create({}). This doesn't seem to work on Oracle.

 DBIx::Class::SQLMaker generates INSERT INTO table DEFAULT VALUES
 RETURNING id INTO ? which, as far as I can figure is not valid syntax
 on Oracle. Neither the is the other common variant for such statements;
 INSERT INTO table () VALUES ().


 This is clearly a bug that we've never tested for previously. Can you
 please confirm that the following works on your Oracle RDBMS (yes, the
 first ()pair is gone):

 INSERT INTO $tablename VALUES(DEFAULT);


That only works for a table with only one column. For more, you'd need to
repeat DEFAULT for each column. Otherwise you get: SQL Error: ORA-00947:
not enough values.

I wonder how/if an explicit DEFAULT interacts with the typical scenario of
having a before insert trigger pulling IDs from a sequence to implement
auto increment columns...

I guess, in a sense, that question boils down whether there's any
difference between:

INSERT INTO t (a, b) VALUES (DEFAULT, 42)

and:

INSERT INTO t (b) VALUES (42)

In any case, I don't know the answer but I suspect we have some resident
Oracle experts who do... I'll discuss it with them and report back...

/L




 ___
 List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class
 IRC: irc.perl.org#dbix-class
 SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/
 Searchable Archive: http://www.grokbase.com/group/
 dbix-class@lists.scsys.co.uk

___
List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class
IRC: irc.perl.org#dbix-class
SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/
Searchable Archive: http://www.grokbase.com/group/dbix-class@lists.scsys.co.uk

Re: [Dbix-class] Database too big.

[Lasse Makholm]

I have little experience with postgres myself, but it seem to that if you
just want to split the database but keep one DBIx::Class schema, you should
be able to do that using the postgres' schema search path which allows you
to refer to tables in schemas other than the current without qualifying the
tables names.

/L


On Thu, Apr 3, 2014 at 5:19 PM, Bill Moseley mose...@hank.org wrote:




 On Thu, Apr 3, 2014 at 7:07 AM, Peter Rabbitson rabbit+d...@rabbit.uswrote:

 On Thu, Apr 03, 2014 at 05:47:18AM -0700, Bill Moseley wrote:
 
  One option is to hunt down every use of $schema for the subset of tables
  and replace it with $other_schema.

 This is what I would recommend. Can you give ideas of the scale of
 changes required?


 Hard to quantify.  It's a few big apps and command-line utilities.   It's
 just normal work to hunt down every possible usage.   Making lots of
 changes has its risks, too.

 But, not everything is as simple as literal $schema-resultset( ... )
 lines everywhere, of course. There's code that says Oh, this things works
 with Foo, or this is Foo controller so I'll use $schema-resltset(
 'Foo' ). That is, much of the high-level code assumes a single $schema.

 DBIC is the common later, which would make it handy to solve there.

  But, is there anything I might do that is a bit more clever?:
 
  $schema-resultset( 'Foo' )  # uses one database
  $schema-resultset( 'Bar' )  # uses a different connection

 A schema object is by definition a proxy that ties mutliple sources and
 a *single* storage object together. As such cleverness in this area is
 likely to bite you. I can not think of specifics at this moment, but the
 gut feeling is don't do it.


 Well, gut felling is a valid response.

 Perhaps a different animal, but the replication code manages multiple
 database connections which made me think about doing something similar at
 the $storage layer.

 Thanks,


 --
 Bill Moseley
 mose...@hank.org

 ___
 List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class
 IRC: irc.perl.org#dbix-class
 SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/
 Searchable Archive:
 http://www.grokbase.com/group/dbix-class@lists.scsys.co.uk

___
List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class
IRC: irc.perl.org#dbix-class
SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/
Searchable Archive: http://www.grokbase.com/group/dbix-class@lists.scsys.co.uk

Re: [Dbix-class] Features comparison among ORMS?

[Lasse Makholm]

On Tue, Nov 12, 2013 at 9:16 AM, Patrick Meidl pme...@ist.ac.at wrote:

 On Mon, Nov 11 2013, Rob Kinyon rob.kin...@gmail.com wrote:

  In terms of speed benchmarks, those are mostly useless. 99% of the
  time spent within an ORM is actually time spent within the database.
  90% of that speed is dependent on how badly you designed your tables.

 I would like to object. if you properly designed your tables, and in
 particular if you do proper normalization, the object instantiation is
 a major overhead, which we could only overcome by using HashrefInflator
 in some of our use cases.


Agreed. DBIx::Class has a pretty significant overhead for inflating result
objects. Most of the time this doesn't really matter but occasionally it
does. For big result sets, sometimes the majority of time ends up being
spent, not waiting the database server or doing I/O but in user space doing
Perl gymnastics. Occasionally, we too, find ourselves falling back to raw
DBI. This is probably true of any ORM though - at least to some degree.
Convenience comes at a cost...

Also, as mentioned earlier, the power of the result set concept in
DBIx::Class shouldn't be underestimated. It's an extremely powerful feature.

/L
___
List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class
IRC: irc.perl.org#dbix-class
SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/
Searchable Archive: http://www.grokbase.com/group/dbix-class@lists.scsys.co.uk