> "Octavian" == Octavian Rasnita writes:
Octavian> What do you think it is the preferable way of passing the
Octavian> parameters to the custom methods defined in the ResultSet
Octavian> class for other more complex methods like ->search(),
Octavian> update(), create(), update
ms);
}
I am not sure which would be the most maintainable method yet...
Octavian
- Original Message -
From: "Eden Cardim"
To: "DBIx::Class user and developer list"
Sent: Sunday, June 27, 2010 4:41 AM
Subject: Re: [Dbix-class] minimalistic Moose / DBIC glu
> "John" == John Napiorkowski writes:
John> I generally try to do this as well, however I find that doing
John> this for simple finds on primary keys gets a bit tedious, and
John> frankly I wonder if I'm not wasting time and adding to
John> complexity. Would be interested in
- Original Message
> From: Eden Cardim
> To: DBIx::Class user and developer list
> Sent: Wed, June 23, 2010 12:53:02 PM
> Subject: Re: [Dbix-class] minimalistic Moose / DBIC glue module
>
> >>>>> "Drew" == Drew Taylor <
> ymailt
> "Drew" == Drew Taylor writes:
Drew> I had thought in the past about where to separate the business
Drew> logic. Do I do it in MyApp::Hotel or
Drew> MyApp::Schema::Result::Hotel? Obviously canned queries go in
Drew> MyApp::Schema::ResultSet::Hotel, but where's the dividing l
I had thought in the past about where to separate the business logic.
Do I do it in MyApp::Hotel or MyApp::Schema::Result::Hotel? Obviously
canned queries go in MyApp::Schema::ResultSet::Hotel, but where's the
dividing line between an operation on a Result object? What policies
are other people
On Wed, Jun 23, 2010 at 5:09 AM, Eden Cardim wrote:
>
> Have you considered using bridge objects + delegation instead? The
> separation between storage and business logic is something you're going
> to want in the future anyway.
Thanks for pointing out delegation. Delegating search(), create(), e
> "BUCHMULLER" == BUCHMULLER Norbert writes:
BUCHMULLER> So I came up with a more minimalistic approach that only
BUCHMULLER> solves the above two problems and nothing else:
BUCHMULLER> 1. it installs Moose accessors on the Result (Row)
BUCHMULLER> objects that perform get_col
On Tue, May 25, 2010 at 12:28 PM, BUCHMULLER Norbert wrote:
> Hi Guys,
>
> at the company where I work we are trying to make DBIC and Moose
> befriend: ie. making the Result (Row) objects regular Moose objects (as
> much as reasonable), so that we can use type constraints, triggers, ... on
> colum
On Wed, 26 May 2010 06:11:53 +0200 Moritz Onken wrote:
> Feel free to use the namespace.
Hi Moritz,
thanks!
norbi
___
List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class
IRC: irc.perl.org#dbix-class
SVN: http://dev.catalyst.perl.org/re
On Tue, 25 May 2010 21:28:45 +0200, BUCHMULLER Norbert
wrote:
> Hi Guys,
>
> at the company where I work we are trying to make DBIC and Moose
> befriend: ie. making the Result (Row) objects regular Moose objects (as
> much as reasonable), so that we can use type constraints, triggers, ...
on
> co
Hi Guys,
at the company where I work we are trying to make DBIC and Moose
befriend: ie. making the Result (Row) objects regular Moose objects (as
much as reasonable), so that we can use type constraints, triggers, ... on
columns as if they were normal attributes.
With the current best practice of
12 matches
Mail list logo
