Re: [Dbix-class] Moose

2010-07-11 Thread Leandro Hermida 
On Sat, Jul 10, 2010 at 8:07 PM, John Napiorkowski jjn1...@yahoo.com wrote:

 - Original Message 
 From: Leandro Hermida soft...@leandrohermida.com
 To: DBIx::Class user and developer list dbix-class@lists.scsys.co.uk
 Sent: Fri, July 9, 2010 4:41:57 AM
 Subject: [Dbix-class] Moose

 Hi all,

 Been an avid DBIx::Class user for a long time and something I've  been
 looking for on CPAN on and off also for a long time and thought  maybe
 it would be possible now that Moose has made such an impact and  good
 OO paradigm programming can be done in Perl... in Java EE (gasp!)  you
 have such a thing as JPA, where you define in a standard way  classes
 for your entity/data objects and via object/relational  metadata
 (annotations in Java) define in these classes the  relationships
 between the entities and any ORM mapping particulars that  the
 underlying ORM engine should use. The underlying ORM  transparently
 handles how the relational schema should map for the particular  RDBMS
 being used and ones does queries in an object-centric way and also  the
 ORM handles how this maps to the appropriate SQL for the schema,  you
 get the idea.

 I always thought JPA was a nice concept since if one  is doing OO
 programming this is the way one should be thinking about their  data
 model. Now there are object persistence frameworks in Perl like  e.g.
 KiokuDB but they don't do real ORM (unless I didn't read  something
 right) and one might argue why do I need ORM and not just persist  the
 objects in a store? There are many common reasons where ORM  is
 required, off the top of my head the fact that commonly other  systems
 will need to interact with your database and can only work with  SQL
 and therefore need to see a proper relational data model. There  are
 also other frameworks like Fey::ORM and Tangram but these  seem
 dangerous to use in any serious project because they have the  common
 CPAN problem that they don't have a big enough developer  community
 behind it and/or aren't even really maintained or developed  further
 anymore (no offense to the people behind these libraries at all,  they
 are probably very nice frameworks, but you can understand how scary  it
 can be to use something like this at work in a big project)

 I used to feel the same way about Fey, but I know several very smart people 
 are
 using it for production level work, so to a degree I feel more comfortable 
 with
 it.


Good point, but still a hard sell to developer colleagues who already
don't like how CPAN works and have gotten burnt in the past.  With
DBIx::Class there seems to be a lot of momentum, people, etc. behind
the project and it has become a standard module which is really great!



 Anyway  sorry for the babble, is it possible with Moose and using
 DBIx::Class as the  underlying ORM engine to create something a la JPA?
 Or will it be possible  once DBIx::Class 0.09 series comes out and is
 more Moose-based?  I've  looked through the archives and on googling
 and haven't really seen any clear  approaches.

 I know mst has been quietly working on a DBIC2 thing, which I am not certain
 will fit your JPA like bill, but given the presentations and talks I've heard 
 it
 might be something even more interesting.


This sound really exciting, I think I saw on of his talks too on the
web regarding the future of DBIC and there were a lot of cool ideas!

 You also might want to look at KiokuDB, which integrates with DBIC and gives 
 you
 some ability to just declare stuff in Moose and get persistance, although its
 not intended to be an ORM.  It does have a very active development community
 around it.  You should take a look.


I had a look at KiokuDB, its a very nice project and suitable for
certain needs, but it doesn't do ORM. In many software development
projects particularly business-related you really the database to be a
relational implementation of your entity object model because you have
other systems, software and programming languages that will be
interacting with the database.


 best,
 Leandro


___
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] Weird INSERT RETURNING error after updating to DBIx::Class .08123

2010-07-11 Thread Steve Kleiman 
Searched the archives on this and didn't see anyone else raise the issue

Just upgraded to DBIx::Class .08123 from 08120.

I see in the Changelog:

 DBIx::Class
 0.08121 2010-04-11 18:43:00 (UTC)
- Add core support for INSERT RETURNING (for storages that supports 
 this syntax, currently PostgreSQL and Firebird)

I'm using Postgres. Before the update, a simple create query was dispatched as:
 INSERT INTO project.vendor_view ( name, project, 
 classification_xref) VALUES ( 1277144170, 3819016, 10 );


That worked great and returned the last_insert_id as expected.

After upgrading to DBIx::Class . 08123, the SQL generated is now:
 INSERT INTO project.vendor_view ( name, project, 
 classification_xref) VALUES ( 1277144170, 3819016, 10 ) RETURNING id


And that throws the error:
 ERROR:  cannot perform INSERT RETURNING on relation vendor_view
 HINT:  You need an unconditional ON INSERT DO INSTEAD rule with a RETURNING 
 clause.

I see in DBIX::Class::Storage::DBI::Pg the comment:
 # only used when INSERT ... RETURNING is disabled
 sub last_insert_id {
 ...
 }

Seems to me I want to disable the RETURNING functionality to make the behavior 
like it was, but I can't figure out how to do that.

Anyone else experienced this?

Thanks in advance.

-steve kleiman
___
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