On 5/22/07 8:07 PM, Matt S Trout wrote:
I discussed merging the projects with jcs a while back but he didn't see the
point of the ResultSet chaining system, which I consider DBIC's key killer
feature
I just didn't think a merge made sense since the two projects have different
philosophies and
On Wed, May 23, 2007 at 11:05:44AM -0400, John Siracusa wrote:
In the meantime, RDBO is a brilliantly well-written system and if you're
with
jcs in not seeing the point of the (functional-ish/set-arithmetic-ish
resultset concept) and not wanting to be able to subclass to override at any
On 5/23/07 12:47 PM, Matt S Trout wrote:
I tend to think in terms of conceptual mapping rather than in terms of
API details, and I think I could fairly easily implement the DBIC API atop
RDBO and vice versa (modulo the odd missing feature on either side)
Sure, but what would the result look
Christopher H. Laco [EMAIL PROTECTED] wrote on 05/23/2007 12:49:20
PM:
John Siracusa wrote:
[snip]
Yes, I've always considered this all prototype work for Perl
6...although
then we have to allow for the first two throw-away ORMs for Perl 6as we
all
Let the CDBI port take care of
I'm considering trying to port Ruby's ActiveRecord to Perl
as a lightweight ORM option (with some small changes
maybe, like composite PKs). If anyone's interested, toss
me a message privately and we'll coordinate.
What I found missing in DBIx::Class is AR method find_by_sql(sql).
We use
Adam Bartosik wrote:
I'm considering trying to port Ruby's ActiveRecord to Perl
as a lightweight ORM option (with some small changes
maybe, like composite PKs). If anyone's interested, toss
me a message privately and we'll coordinate.
What I found missing in DBIx::Class is AR method
I'm considering trying to port Ruby's ActiveRecord to Perl as
a lightweight ORM option (with some small changes maybe, like
composite PKs). If anyone's interested, toss me a message
privately and we'll coordinate.
Why not simply colaborate to extend DBIx?
--
Eduard Giménez
CAPSiDE
I'm currently trying to decide on Catalyst or Rails for a new project.
I like the flexibility of Catalyst (and love Perl), but I'm attracted to
a lot of the design decisions in Rails (I like the fact, for example,
that ActiveRecord::Validations supports data validation in the model,
just like we
On Tue, May 22, 2007 at 09:33:37AM +0200, Adam Bartosik wrote:
I'm considering trying to port Ruby's ActiveRecord to Perl
as a lightweight ORM option (with some small changes
maybe, like composite PKs). If anyone's interested, toss
me a message privately and we'll coordinate.
What I found
On 5/22/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
one thing i really like about AR is the association proxies, where
relationships themselves are objects you can call methods (ie, find) on
class User ActiveRecord::Base
has_many :items
end
class Item ActiveRecord::Base
On 5/22/07, Adam Bartosik [EMAIL PROTECTED] wrote:
I doubt there's anything worth porting in ActiveRecord that one of the
many Perl options (DBIx::Class, Rose::DB::Object, Class::DBI, Tangram,
Alzabo) doesn't provide.
- Perrin
one thing i really like about AR is the association proxies,
-Original Message-
From: mla [mailto:[EMAIL PROTECTED]
Sent: Tuesday, May 22, 2007 4:25 AM
To: The elegant MVC web framework
So part of me would like to see a more Rails-like layer on top of
Catalyst.
Sounds like you really want to write a Rails-like layer for Catalyst!
Disclaimer:
On Tue, May 22, 2007 at 06:53:00AM -0700, [EMAIL PROTECTED] wrote:
On 5/22/07, Adam Bartosik [EMAIL PROTECTED] wrote:
I doubt there's anything worth porting in ActiveRecord that one of the
many Perl options (DBIx::Class, Rose::DB::Object, Class::DBI, Tangram,
Alzabo) doesn't provide.
What would that achieve that passing literal SQL chunks for SELECT, FROM,
WHERE etc. wouldn't?
Readability. Complex SQL statements are more clear to understand than
complex dbix statements when you are not an author of DBIX ;)
I can also test it with simple copypaste to sql console to see how
On Tue, May 22, 2007 at 05:36:18PM +0200, Adam Bartosik wrote:
What would that achieve that passing literal SQL chunks for SELECT, FROM,
WHERE etc. wouldn't?
Readability. Complex SQL statements are more clear to understand than
complex dbix statements when you are not an author of DBIX ;)
I agree with you, using DBIx for simple stuff is fine, but after a while raw
SQL is sometimes nice to have.
I cant figure out how to return the data in object form, but this will at
least give you some data:
__PACKAGE__-load_components(qw/
ResultSetManager
PK::Auto
Core
So here's the one big remaining question - why haven't you worked out what
syntax you'd like to see for this feature and started a thread on the
dbix-class list to discuss it? :)
Good point. To be honest - I need to dig deeply into dbix structure to
propose something in the dbix way.
The main
On Tue, May 22, 2007 at 11:52:22AM -0400, John Goulah wrote:
I agree with you, using DBIx for simple stuff is fine, but after a while raw
SQL is sometimes nice to have.
Personally I find it worthwhile to reformulate queries in DBIC form - I find
complex queries are usually there for reporting
On Tue, May 22, 2007 at 01:14:31PM -0300, Eden Cardim wrote:
On 5/22/07, Adam Bartosik [EMAIL PROTECTED] wrote:
Good point. To be honest - I need to dig deeply into dbix structure to
propose something in the dbix way.
The main feature I would like to get from dbix as a wrapper for SQL
On May 22, 2007, at 7:58 AM, Matt S Trout wrote:
item = user.items.find(params[:id])
my $item = $user-items-find($item_id);
new_item = user.items.create!(params[:item])
my $new_item = $user-items-create(\%item_info);
that's great; i thought i had recalled something similar, but
On Tue, May 22, 2007 at 09:29:25AM -0700, Michael Reece wrote:
On May 22, 2007, at 7:58 AM, Matt S Trout wrote:
item = user.items.find(params[:id])
my $item = $user-items-find($item_id);
new_item = user.items.create!(params[:item])
my $new_item = $user-items-create(\%item_info);
John Napiorkowski wrote:
--- Eduard Giménez [EMAIL PROTECTED] wrote:
I'm considering trying to port Ruby's ActiveRecord
to Perl as
a lightweight ORM option (with some small changes
maybe, like
composite PKs). If anyone's interested, toss me a
message
privately and we'll coordinate.
Why
Perrin Harkins wrote:
On 5/22/07, Adam Bartosik [EMAIL PROTECTED] wrote:
What I found missing in DBIx::Class is AR method find_by_sql(sql).
Did you ask about it on the mailing list? Nearly all of the Perl ORMs
have support for direct SQL. I don't know DBIx::Class, but
search_literal sounds
mla wrote:
Christopher H. Laco wrote:
mla wrote:
Perrin Harkins wrote:
On 5/22/07, Adam Bartosik [EMAIL PROTECTED] wrote:
What I found missing in DBIx::Class is AR method find_by_sql(sql).
Did you ask about it on the mailing list? Nearly all of the Perl ORMs
have support for direct SQL. I
mla wrote:
Christopher H. Laco wrote:
mla wrote:
Perrin Harkins wrote:
On 5/22/07, Adam Bartosik [EMAIL PROTECTED] wrote:
What I found missing in DBIx::Class is AR method find_by_sql(sql).
Did you ask about it on the mailing list? Nearly all of the Perl ORMs
have support for direct SQL. I
On 5/22/07, mla [EMAIL PROTECTED] wrote:
If I may ask, Perrin, what do you use?
I have a large system that was started back when Class::DBI was a hot
new thing. It still uses CDBI and hasn't really had a good reason to
change, since we use a lot of custom SQL and that's pretty easy to do
with
On Tue, May 22, 2007 at 12:03:43PM -0700, mla wrote:
Okay, thanks. I will do that. I'm mainly looking to
strip features, not match them.
DBIx::Class' component architecture makes it easy to do that too.
It's pretty much an ORM construction kit that just happens to provide
a default recipe :)
Christopher H. Laco wrote on 5/22/07 2:47 PM:
Well, to be fair to RDBO, I'm just not as familiar with it as I am with
DBIC. When I was doing the storage layer for RDBO, what I missed (aside
from deploy) was the *_related methods and the fact that resultsets are
chainable. DBIC appears to take
On Tue, May 22, 2007 at 03:46:16PM -0500, Peter Karman wrote:
Christopher H. Laco wrote on 5/22/07 2:47 PM:
Well, to be fair to RDBO, I'm just not as familiar with it as I am with
DBIC. When I was doing the storage layer for RDBO, what I missed (aside
from deploy) was the *_related
29 matches
Mail list logo
