Re: [Dbix-class] Re: OO advice ... do a subclass? .. do something else?
On Fri, Oct 8, 2010 at 7:06 AM, Will Hawes wrote:
>
> > [ snip ]
> >
> > Currently I have a method in my ResultSet class for tickets called
> > something like 'create_typeX' .. this method wraps the logic that
> > creates the ticket and all relationships for that type.
> >
> > [ snip ]
> >
> > I think I need to do a subclass of my ticket ResultSet?.. but I am not
> > sure and wanted to ask people who actually know what they are doing ;)
> >
> > Some stuff in my head is, should I sub-class my ticket ResultSet?..
> > should I somehow use a Role/Trait? .. should I have something that sits
> > ontop of my Schema and applies the business logic to it?
> >
> > Any advice/links/examples you can provide would be greatly appreciated.
>
> It sounds like
> http://search.cpan.org/~frew/DBIx-Class-0.08123/lib/DBIx/Class/Manual/Cookbook.pod#Dynamic_Sub-classing_DBIx::Class_proxy_classes
> could be along the lines of what you want.
>
Dynamic sub-classing only affects the Row objects returned by a single
ResultSet. I think Will is interested in custom ResultSet objects. I
would create a single abstract Result class defining the table and the
common columns used by all the various types and then create
sub-classes for each of the specific types that define the appropriate
relationships and any additional relevant columns for that ticket
type. You can then do something like
$schema->resultset('Ticket::Foo')->create({ ... }) or
$schema->resultset('Ticket::Bar')->create( { ... } ) and get the
desired object type.
In my experience, roles have limited use for setting up Result classes
because without a lot of hackery, you can't call class methods within
a role (ala __PACKAGE__->table('tickets') ) so sub-classing seems to
work a lot better for this type of thing.
TMTOWTDI applies...
___
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] convention for naming primary keys to avoid ambiguousselects
prefixing the "id" column with the name of the relationship seems much more
obvious than prefixing the base table's column with "me". This doesn't seem
like it would be too complicated to implement -- if the column given is not
already prefixed by one or more table/relationship aliases, it could be
automatically changed to "me.$col".
On Tue, Nov 25, 2008 at 3:41 PM, Peter Rabbitson
<[EMAIL PROTECTED]<[EMAIL PROTECTED]>
> wrote:
> Noel Burton-Krahn wrote:
> > On Tue, Nov 25, 2008 at 10:22 AM, Peter Rabbitson <[EMAIL PROTECTED]<[EMAIL
> > PROTECTED]>>
> wrote:
> >
> > Consider the following search from a schema where person and address
> > both have a column named 'id':
> >
> > $schema->resultset('Person')->search({ id => $person_id}, { prefetch
> > => [ 'address' ] });
> >
> > This is a reasonable query: load a person with address by the
> > person's id. The 'id' column is unambiguous in the search call.
>
> Excellent example. Now tell me how to express the query "Get me all
> Persons which have an Address with (address.)id == $address_id, while
> prefetching the Address data as well.
>
> ___
> 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] RFC: DBIx-Class-OptimisticLocking
Hello all,
I've checked in a first draft of a DBIx::Class component providing
optimistic locking support and I would appreciate any feedback you might
have. Check it out here:
http://dev.catalyst.perl.org/repos/bast/DBIx-Class-OptimisticLocking/1.000/trunk
>From the README:
DBIx::Class::OptimisticLocking - Optimistic locking support for DBIx::Class
Optimistic locking is an alternative to using exclusive locks when you have
the possibility of concurrent, conflicting updates in your database. The
basic principle is you allow any and all
clients to issue updates and rather than preemptively synchronizing all data
modifications (which is what happens with exclusive locks) you are
"optimistic" that updates won't interfere with one
another and the updates will only fail when they do in fact interfere with
one another.
Consider the following scenario (in timeline order, not in the same block of
code):
my $order = $schema->resultset('Orders')->find(1);
# some other different, concurrent process loads the same object
my $other_order = $schema->resultset('Orders')->find(1);
$order->status('fraud review');
$other_order->status('processed');
$order->update; # this succeeds
$other_order->update; # this fails when using optimistic locking
Without optimistic locking (or exclusive locking), the example order would
have two sequential updates issued with the second essentially erasing the
results of the first. With optimistic
locking, the second update (on $other_order) would fail.
This optimistic locking is typically done by adding additional restrictions
to the "WHERE" clause of the "UPDATE" statement. These additional
restrictions ensure the data is still in the
expected state before applying the update. This
DBIx::Class::OptimisticLocking component provides a few different strategies
for providing this functionality.
Thanks!
Brian Phillips
___
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
