Colin,
Your Russian is very nice!
PerlORM is pretty stable, mature and it is still used in production environment
at my previous ISP job. However the major PerlORM draw back is lack of
active community e.g. compared to DBIx.
Anyway I will be grateful if you point me what is missing in the docs.
Updating the docs won't take too much of my time but might be useful
to other people.
All the best wishes to you!
On 10/8/07, Colin Fine via RT <bug-ORM@rt.cpan.org> wrote:
>
> Queue: ORM
> Ticket <URL:
http://rt.cpan.org/Ticket/Display.html?id=29772 >
>
> Алексей,
>
> спасибо за скорым ответом.
>
>
>
> Я понимаю же работаете теперь на других делах.
>
>
>
> Я хотел использовать какая нибудь система ОРМа, но я не уверен, если
>
> достаточно завершена ваша система для использования в торговой компание.
>
> Это трудно, ей использовать с незавершенной документации. Я часто зашел
>
> проблемы, которые я не мог понимать без осматривать код.
>
>
>
> А если бы у меня время для сотруничания с вами, мне кажется же трудно
>
> понимать и сотрудничать на системе без полной документация.
>
>
>
> Colin
>
>
>
>
>
>
>
>
>
> > Colin Fine
>
> > Engineering Tools Group
>
> > Pace Micro Technology plc
>
> > Bringing Technology Home
>
> >
>
> >
>
> > Tel: +44 1274 538038
>
> > Fax: +44 1274 532029
>
> > Victoria Road, Saltaire, West Yorkshire. BD18 3LF www.pacemicro.com
>
> >
>
> This E-mail and any attachments hereto are strictly confidential and intended solely for the addressee. If you are not the intended addressee please notify the sender by return and delete the message. You must not disclose, forward or copy this E-mail or attachments to any third party without the prior consent of the sender. Pace Micro Technology plc (registered in England and Wales no. 1672847) whose head office is based at Victoria Road, Saltaire, West Yorkshire, BD18 3LF, UK. Tel +44 (0) 1274 532000 Fax +44 (0) 1274 532010 and at
http://www.pacemicro.com.
>
>
>
>
>
>
>
>
>
> -----Original Message-----
>
> From: Alexey Akimov via RT [mailto:bug-ORM@rt.cpan.org]
>
> Sent: 07 October 2007 23:45
>
> To: Colin Fine
>
> Subject: Re: [rt.cpan.org #29772] After find_or_new, update fails when
>
> there is a timestamp field.
>
>
>
>
>
>
>
> <URL:
http://rt.cpan.org/Ticket/Display.html?id=29772 >
>
>
>
> Hi Colin,
>
>
>
> Thanks for the report.
>
> As you correctly supposed the problem is that ORM does
>
> not know the faсt that server changes proposed value
>
> for 'when' field.
>
>
>
> There are 2 ways to deal with this:
>
>
>
> 1. Workaround: make ORM set values for timestamp fields.
>
> It assumes you add following into Test/Data.pm or to Tets/ORM.pm.
>
> In latter case you define common behaviour for 'when' fields in
>
> any orm-class in your hierarchy.
>
>
>
> sub new
>
> {
>
> my $class = shift;
>
> my %arg = @_;
>
> my $prop = $arg{prop};
>
>
>
> if( $class->_has_prop( 'when' ) && !$prop->{when} )
>
> {
>
> $prop = {};
>
> %$prop = %{$arg{prop}};
>
> $prop->{when} = time;
>
> }
>
>
>
> $class->SUPER::new
>
> (
>
> prop => $prop,
>
> error => $arg{error},
>
> temporary => $arg{temporary},
>
> suspended => $arg{suspended},
>
> history => $arg{history},
>
> );
>
> }
>
>
>
> If you need timestamp field to be updated on every update
>
> then you can handle it similar way using _validate_prop() method.
>
>
>
> 2. Fix: implement lazy_load on per field basis (last line in TODO.txt)
>
> In that case it will be possible to make timestamp field
>
> permanently 'lazy' and never count on its value during updates.
>
>
>
> Unfortunately since i changed my job and switched to
>
> development using python, i don't have enought time to develop
>
> the project alone, so i can't give you estimate on when
>
> described fix will come to life, but if you interested
>
> in it i am appreciate any cooperation.
>
>
>
> On Thu, 04 Oct 2007 18:58:26 +0400, Colin Fine via RT
>
> <bug-ORM@rt.cpan.org> wrote:
>
>
>
> >
>
> > Thu Oct 04 10:58:18 2007: Request 29772 was acted upon.
>
> > Transaction: Ticket created by COLINFINE
>
> > Queue: ORM
>
> > Subject: After find_or_new, update fails when there is a timestamp
>
> > field.
>
> > Broken in: 0.83
>
> > Severity: Normal
>
> > Owner: Nobody
>
> > Requestors: colin.fine@pacemicro.com
>
> > Status: new
>
>
> >
>
> >
>
> > With a Database table that contains a 'timestamp' field, if I use
>
> > find_or_new to create a new object and record, then update it, the
>
> > update fails.
>
> >
>
> > "ORM::Db::DBI::MySQL->ORM::Db::DBI::update_object_part(): Failed to
>
> > update object with id#7 of class 'Test::Data', 0 rows affected, may be
>
> > object was updated elsewhere."
>
> >
>
> > I think this is because the find_or_new has not realised that the
>
> > 'timestamp' field has been automatically set in the database, so the
>
> > following update, which specifies the field as empty, does not match any
>
> > rows.
>
> >
>
> > I thought this might be a consequence of using lazy_load, but I've tried
>
> > it with lazy_load both on and off, and it doesn't make any difference.
>
> >
>
> > The workround seems to be to call an explicit 'refresh' after the
>
> > 'find_or_new', but you don't need this when there isn't a timestamp.
>
> >
>
> > I suspect the fix is to exclude any timestamp fields from the match in
>
> > 'update' unless the calling code has specifically set them; but I don't
>
> > know if this is too general and would have other repercussions.
>
> >
>
> > perl 5.8.5
>
> > Fedora Core 3
>
> > MySQL 4.1.22-standard
>
> >
>
> > Attached:
>
> > ormtest.sql - defines the database
>
> > testorm.tar.gz - the cgi and pm files.
>
> >
>
> >
>
> >
>
>
>
>
>
>
>
> --
>
> Best regards, Alexey Akimov
>
>
>
>
>
>
>
> Click
https://www.mailcontrol.com/sr/wQw0zmjPoHdJTZGyOCrrhg== to report this email as spam.
>
>
