Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Catalyst: Users

DBIC and RDBO compared (was: Choosing the right ORM)

 

 

Catalyst users RSS feed   Index | Next | Previous | View Threaded


siracusa at mindspring

Nov 30, 2005, 3:47 PM

Post #1 of 15 (14317 views)
Permalink
DBIC and RDBO compared (was: Choosing the right ORM)

On 11/28/05 6:47 PM, Uwe Voelker wrote:
> On Mon, 2005-11-28 at 14:00 +0100, catalyst [at] augensalat wrote:
>> There are other ORMs available, but only one, DBIx::Class gets
>> some attention here.
>> How about Alzabo or Rose::DB::Object or maybe others?
>
> John and Matt, can you please give a feature comparison of RDBO and
> DBIC?

Sure, here's a summary. I wrote it and Matt provided some feedback
and corrections.

Let's start with the common features. Both DBIx::Class (DBIC) and
Rose::DB::Object (RDBO) can do the following.

---

COMMON FEATURES

* Insert, select, update, and delete individual rows based on a
primary key.

* Multi-column primary keys are supported.

* Auto-increment and sequence-based primary keys are supported.

* Relate rows in one table to rows in another table through foreign
keys and other relationships (1 to N, N to 1, and N to N), going
through a linking table for "N to N" relationships.

* Multi-column foreign keys are supported.

* Queries support arbitrarily nested boolean logic.

* Fetch multiple rows, optionally from more than one table in a
single query via one-to-one or many-to-one relationships using SQL
JOINs.

* Support for both "all at once" and iterator styles of queries.
Iterators fetch from the database only as needed.

* Limit/offset supported where possible, and emulated where not. A
"page"-based interface is also provided.

* Column values may be "inflated" and "deflated" as needed.

* Column values maybe "lazily loaded," meaning that are fetched from
the database at the last possible moment rather then being loaded up
front.

* Column aliasing for column names that conflict with reserved method
names.

* A "loader" can automatically build a family of classes based on a
collection of tables by extracting the relevant information from the
database: column names, primary keys, and foreign keys. N-to-1 and 1-
to-N relationships will be set up automatically based on foreign key
information.

* Support for "client-side" cascaded delete.

* Support for MySQL, Postgres, and SQLite databases.

---

Next, features that are unique to each module. (That is, "unique" as
compared to each other, not necessarily "unique among all Perl ORM
modules.")

---

UNIQUE DBIC FEATURES

* Class::DBI compatibility layer.

* ADO support in the loader.

* MSSQL and Oracle primary key detection and configuration.

* Supports arbitrary-depth explicit joins.

* Supports arbitrary-depth client-side cascaded delete.

* The list of columns fetched during a SELECT (with or without JOINs)
can be be specified exactly.

---

UNIQUE RDBO FEATURES

* Support for Informix.

* Objects may be loaded based on unique keys.

* Extensive column metadata: data types, size limits, default values.

* Bundled set of column classes for most commonly used data types,
with integrated inflate/deflate, validation, and other convenience
functions.

* The bundled column classes also support some esoteric column types:
Informix SET columns, Postgres CHKPASS, BIT, and array columns.
(Inflate/deflate is done to/from Perl arrays and Bit::Vector objects
as appropriate; Postgres arrays and bitfields are emulated in other
databases.)

* In addition to inflate/deflate, column triggers can also be applied
to get/set (user data) and load/save (to/from database) events.

* Can auto-join via one-to-many and many-to-many relationships,
fetching all data in a single query, preserving custom sort orders
for sub-objects.

* Queries accept "rich" values as arguments (e.g., DateTime and
Bit::Vector objects)

* Bulk update and delete methods, which also work with "rich" query
arguments.

* By default, when an object's related sub-objects are added or
updated through that object, all changes are delayed until the
"parent" object is saved, at which time all outstanding changes occur
within a single transaction. ("Immediate" actions are also supported.)

* Support for "SELECT DISTINCT ..." queries.

* Lazy loading can be overridden on a per-class basis during single
and multi-table queries.

* Database migration: copying objects from one database to another by
trading "db" (Rose::DB) objects. Works across database types (e.g.,
Postgres to MySQL) provided that all column data types exist (or are
emulated) in both places.

* In addition to extracting column names, primary keys, and foreign
keys, the RDBO loader can also do the following:

- Configure column data types, size limits, and default values.
- Extract and configure unique keys.
- Set up all relationship types, including many-to-many relationships.

* All automatic behavior and naming conventions are encapsulated in a
"convention manager" object. Using different convention managers
will alter the behavior of the loader and other automatic processes.
(e.g., A "Rails" convention manager could enforce the Ruby on Rails
naming conventions for classes and tables.)

---

DBIC and RDBO have different recommended methods of extension.

--

EXTENDING DBIC

DBIC uses multiple inheritance and the Class::C3 module. Behavior is
modified by inheriting from a certain set of classes, or
"components." New behavior is added by creating new classes which
can be added to the inheritance tree.

EXTENDING RDBO

RDBO uses traditional subclassing and delegation. Each component of
the system can be swapped out for a custom subclass or a new class
that implements the expected API. Single inheritance is expected,
but not enforced.

--

The design goals differ in the following ways.

--

DESIGN GOALS

* DBIC is designed to support storage systems other than DBI. RDBO
is only designed to support DBI.

* Performance is an important goal of RDBO. It's currently the
fastest Perl ORM module among those tested in this benchmark:

http://rose.sourceforge.net/wiki/index.php/RDBO/Benchmark

DBIC is the second fastest in the benchmark, but performance is a
less important goal for DBIC than for RDBO.

---

-John



_______________________________________________
Catalyst mailing list
Catalyst [at] lists
http://lists.rawmode.org/mailman/listinfo/catalyst


perrin at elem

Nov 30, 2005, 4:23 PM

Post #2 of 15 (13622 views)
Permalink
Re: DBIC and RDBO compared (was: Choosing the right ORM) [In reply to]

On Wed, 2005-11-30 at 18:47 -0500, John Siracusa wrote:
> UNIQUE DBIC FEATURES
>
> * Class::DBI compatibility layer.
>
> * ADO support in the loader.
>
> * MSSQL and Oracle primary key detection and configuration.
>
> * Supports arbitrary-depth explicit joins.
>
> * Supports arbitrary-depth client-side cascaded delete.
>
> * The list of columns fetched during a SELECT (with or without JOINs)
> can be be specified exactly.

One important feature which Class::DBI supports (and I assume DBIC
supports this as well) is the use of arbitrary SQL to fetch objects.
Some database operations are just much better expressed in SQL than in a
complex perl data structure, especially if you want access to vendor-
specific extensions like the Oracle tree stuff. With Class::DBI, you
can write some hairy SQL query and let it do all the drudge work to turn
the resulting rows into objects. This is a key feature for me.

- Perrin


_______________________________________________
Catalyst mailing list
Catalyst [at] lists
http://lists.rawmode.org/mailman/listinfo/catalyst


siracusa at mindspring

Nov 30, 2005, 4:34 PM

Post #3 of 15 (13601 views)
Permalink
Re: DBIC and RDBO compared (was: Choosing the right ORM) [In reply to]

On 11/30/05 7:23 PM, Perrin Harkins wrote:
> One important feature which Class::DBI supports (and I assume DBIC
> supports this as well) is the use of arbitrary SQL to fetch objects.
> Some database operations are just much better expressed in SQL than in a
> complex perl data structure, especially if you want access to vendor-
> specific extensions like the Oracle tree stuff. With Class::DBI, you
> can write some hairy SQL query and let it do all the drudge work to turn
> the resulting rows into objects. This is a key feature for me.

RDBO supports raw SQL in the WHERE clause, if desired. There's also a
get_objects_from_sql() Manager method that's currently commented out:

http://search.cpan.org/src/JSIRACUSA/Rose-DB-Object-0.54/lib/Rose/DB/Object/
Manager.pm

I just can't think of anything it can do that can't be done better using one
of the other features. If you can give me some example scenarios, that'll
help me get an idea of what people actually use this kind of feature for.

-John



_______________________________________________
Catalyst mailing list
Catalyst [at] lists
http://lists.rawmode.org/mailman/listinfo/catalyst


perrin at elem

Nov 30, 2005, 4:56 PM

Post #4 of 15 (13600 views)
Permalink
Re: DBIC and RDBO compared (was: Choosing the right ORM) [In reply to]

On Wed, 2005-11-30 at 19:34 -0500, John Siracusa wrote:
> I just can't think of anything it can do that can't be done better
> using one
> of the other features. If you can give me some example scenarios,
> that'll
> help me get an idea of what people actually use this kind of feature
> for.

I mentioned Oracle's tree extensions. You can also do complex outer
join scenarios, subselects, GROUP BY with HAVING clauses, full-text
search extensions, etc. There's also some use for managing locking with
things like SELECT..FOR UPDATE grabbing a bunch of objects and holding
read locks on them until the commit. And there's really esoteric stuff
like extensions for working with polygon data.

Databases are just too complicated to totally abstract away. I want
help with all the easy stuff, but sometimes the hard stuff requires
direct SQL.

By the way, did the new prepare_cached() work improve performance
noticeably?

- Perrin


_______________________________________________
Catalyst mailing list
Catalyst [at] lists
http://lists.rawmode.org/mailman/listinfo/catalyst


siracusa at mindspring

Nov 30, 2005, 5:39 PM

Post #5 of 15 (13604 views)
Permalink
Re: DBIC and RDBO compared (was: Choosing the right ORM) [In reply to]

On 11/30/05 7:56 PM, Perrin Harkins wrote:
> I mentioned Oracle's tree extensions. You can also do complex outer
> join scenarios, subselects, GROUP BY with HAVING clauses, full-text
> search extensions, etc. There's also some use for managing locking with
> things like SELECT..FOR UPDATE grabbing a bunch of objects and holding
> read locks on them until the commit. And there's really esoteric stuff
> like extensions for working with polygon data.
>
> Databases are just too complicated to totally abstract away. I want
> help with all the easy stuff, but sometimes the hard stuff requires
> direct SQL.

Well, like I said, for anything in the WHERE clause, there's no problem. I
use sub-selects and weird comparison operators and such all the time in that
situation.

For GROUP BY, there is a bit of a a problem when using any ORM that requires
each object to have a primary key. If you just want to use an object as a
temporary container for row data, it'll be okay, but it's still not a good
match.

SELECT...FOR UPDATE sounds like a good feature to add to the Manager.

For funky SQL in the FROM clause or the column list, then it's really raw
SQL time. But in that situation, it's usually difficult or impossible for
an ORM to do anything sensible with the results.

Let's say I do a weird 6-table join, selecting columns from various (but not
all) tables, plus a bunch of derived values and sub-selected values and
function calls. Doing fetchrow_hashref on that gives me a pretty opaque
hash. Unless there's a ORM class that exactly matches the name, number, and
type of columns returned, there's not much that can be automated.

In these situations, what I tend to do is run the custom SQL using DBI and
then instantiate one or more RDBO objects manually from each row. I know
which columns are meant for which objects, so it's straightforward. Trying
to specify that information in an abstract is more work, not less.

When you use CDBI to do custom queries, do you make sure that the columns
returned match the expectations of your CDBI class? If so, then my
commented-out get_objects_from_sql() method does the same thing. If not,
then how do you handle mismatches between selected columns (possibly from
multiple tables) and ORM object attributes?

> By the way, did the new prepare_cached() work improve performance
> noticeably?

I only benched MySQL with MyISAM, which doesn't do anything interesting
during prepare() anyway. I'll bench Pg later to see if it makes a
difference. I made several other performance-related changes so it's hard
to attribute the improvements in 0.54 to any one thing without more testing.

Also, I only used prepare_cached() in the places where I expect the SQL to
be identical over time: things like save() and delete(). I don't use it at
all in the Manager, where each query can be different. (And I don't use it
in load() because it causes inexplicably locking issues in Informix...blah.)

-John



_______________________________________________
Catalyst mailing list
Catalyst [at] lists
http://lists.rawmode.org/mailman/listinfo/catalyst


perrin at elem

Nov 30, 2005, 6:05 PM

Post #6 of 15 (13596 views)
Permalink
Re: DBIC and RDBO compared (was: Choosing the right ORM) [In reply to]

On Wed, 2005-11-30 at 20:39 -0500, John Siracusa wrote:
> For GROUP BY, there is a bit of a a problem when using any ORM that requires
> each object to have a primary key. If you just want to use an object as a
> temporary container for row data, it'll be okay, but it's still not a good
> match.

It's useful with HAVING in certain conditions when you can group by the
primary key and use aggregate functions to qualify results based on
joins. It is pretty esoteric though.

> In these situations, what I tend to do is run the custom SQL using DBI and
> then instantiate one or more RDBO objects manually from each row.

That's probably enough for most situations.

> When you use CDBI to do custom queries, do you make sure that the columns
> returned match the expectations of your CDBI class?

Yes.

> If so, then my
> commented-out get_objects_from_sql() method does the same thing.

Sounds pretty similar to what I do with Class::DBI.

> I only benched MySQL with MyISAM, which doesn't do anything interesting
> during prepare() anyway.

It still seems to help MySQL a little because it avoids some object
setup overhead.

> I'll bench Pg later to see if it makes a difference.

I remember it having a huge impact on Oracle, so maybe Pg will be
similar.

> Also, I only used prepare_cached() in the places where I expect the SQL to
> be identical over time: things like save() and delete(). I don't use it at
> all in the Manager, where each query can be different.

I would still use it there, maybe with a switch to disable it. Most
applications have a specific range of queries that they repeat, and it's
typically a pretty small set.

- Perrin


_______________________________________________
Catalyst mailing list
Catalyst [at] lists
http://lists.rawmode.org/mailman/listinfo/catalyst


siracusa at mindspring

Nov 30, 2005, 6:17 PM

Post #7 of 15 (13622 views)
Permalink
Re: DBIC and RDBO compared (was: Choosing the right ORM) [In reply to]

On 11/30/05 9:05 PM, Perrin Harkins wrote:
>> When you use CDBI to do custom queries, do you make sure that the columns
>> returned match the expectations of your CDBI class?
>
> Yes.
>
>> If so, then my commented-out get_objects_from_sql() method does the same
>> thing.
>
> Sounds pretty similar to what I do with Class::DBI.

Hm, then I guess I'll uncomment it for the next release. It does save a lot
of boilerplate typing in this particular situation.

>> Also, I only used prepare_cached() in the places where I expect the SQL to
>> be identical over time: things like save() and delete(). I don't use it at
>> all in the Manager, where each query can be different.
>
> I would still use it there, maybe with a switch to disable it. Most
> applications have a specific range of queries that they repeat, and it's
> typically a pretty small set.

That sounds reasonable. Next release, probably.

-John



_______________________________________________
Catalyst mailing list
Catalyst [at] lists
http://lists.rawmode.org/mailman/listinfo/catalyst


blblack at gmail

Nov 30, 2005, 8:26 PM

Post #8 of 15 (13602 views)
Permalink
Re: DBIC and RDBO compared (was: Choosing the right ORM) [In reply to]

On 11/30/05, John Siracusa <siracusa [at] mindspring> wrote:
> On 11/30/05 7:23 PM, Perrin Harkins wrote:
> > One important feature which Class::DBI supports (and I assume DBIC
> > supports this as well) is the use of arbitrary SQL to fetch objects.
> > Some database operations are just much better expressed in SQL than in a
> > complex perl data structure, especially if you want access to vendor-
> > specific extensions like the Oracle tree stuff. With Class::DBI, you
> > can write some hairy SQL query and let it do all the drudge work to turn
> > the resulting rows into objects. This is a key feature for me.
>
> RDBO supports raw SQL in the WHERE clause, if desired. There's also a
> get_objects_from_sql() Manager method that's currently commented out:
>
> http://search.cpan.org/src/JSIRACUSA/Rose-DB-Object-0.54/lib/Rose/DB/Object/
> Manager.pm
>
> I just can't think of anything it can do that can't be done better using one
> of the other features. If you can give me some example scenarios, that'll
> help me get an idea of what people actually use this kind of feature for.
>
> -John
>

I've brought this up before either here or on the DBIx::Class list,
but one interesting problem I've seen that might give you some food
for thought is SELECTing things other than raw column data, using the
RDBMS builtin functions or user-supplied stored procedures, either of
which may or may not be an aggregating function. A lot of my queries
leverage the RDBMS for data aggregation or post-processing. For
example, in raw SQL:

SELECT min(col_x) as min_col_x, stddev(col_y) as stddev_col_y FROM
atable WHERE itemid IN ( 123, 456, 789, 1234 ) AND t_stamp =
1142412412;

on a table where itemid and t_stamp comprise a compound primary key.
Of course in the real world there's more like 10+ functions being
selected in a query, 30+ "itemid"s, and a whole range of t_stamps,
aggregating hundreds of rows down to a handful of result values.

In DBIx::Class, I formulate it something like: (this is from memory, I
don't have the code in front of me at the moment, might contain
errors...)

my @res = $atable_class->search(
{ itemd => [ 123, 456, 789, 1234 ], t_stamp => 1142412412 },
{ cols => [ 'min(col_x)', 'stddev(col_y)' ] }
);
my $min_col_x = $res[0]->get_column('min(col_x)');
my $stddev_col_y = $res[0]->get_column('stddev(col_y)');

Which I consider to be fairly reasonable all things considered (I was
shocked that it even worked the first time I tried this method).
However it is a bit more klunky than it neccesarily has to be, and I
think there must be a better way to abstract the idea of selecting
functions and/or aggregate functions off of database columns better
than this. This case is relatively simple, other complexities lurk in
handling the whole general case correctly (especially if you get into
GROUP BY clauses and all that).

-- Brandon

_______________________________________________
Catalyst mailing list
Catalyst [at] lists
http://lists.rawmode.org/mailman/listinfo/catalyst


phil at 2people

Dec 1, 2005, 8:59 AM

Post #9 of 15 (13601 views)
Permalink
Re: DBIC and RDBO compared (was: Choosing the right ORM) [In reply to]

On 11/30/05, John Siracusa <siracusa [at] mindspring> wrote:
> On 11/28/05 6:47 PM, Uwe Voelker wrote:
> > On Mon, 2005-11-28 at 14:00 +0100, catalyst [at] augensalat wrote:
> >> There are other ORMs available, but only one, DBIx::Class gets
> >> some attention here.
> >> How about Alzabo or Rose::DB::Object or maybe others?
> >
> > John and Matt, can you please give a feature comparison of RDBO and
> > DBIC?
>
> Sure, here's a summary. I wrote it and Matt provided some feedback
> and corrections.
>

Thanks for this great overview! You don't mention anything wrt
inheritance of model classes -- probably it's too obvious to mention.
But as someone w/o a lot of ORM experience, I'm wondering how these
handle situations outside the one class/one table model --
specifically, where you have an inheritance tree that's all based on
the same table, and where there's a signficant amount of implicit
self-joins. I do this now in CDBI using has_a/has_many, but have run
into as-yet-unexplained breakdown of inheritance of triggers and such,
which I solve with ugly workarounds.
--
==========================
2People Blog: http://2-people.blogspot.com/
2People site: http://www.2people.org

_______________________________________________
Catalyst mailing list
Catalyst [at] lists
http://lists.rawmode.org/mailman/listinfo/catalyst


siracusa at mindspring

Dec 1, 2005, 10:29 AM

Post #10 of 15 (13603 views)
Permalink
Re: DBIC and RDBO compared (was: Choosing the right ORM) [In reply to]

On 12/1/05, Phil Mitchell <phil [at] 2people> wrote:
> Thanks for this great overview! You don't mention anything wrt
> inheritance of model classes -- probably it's too obvious to mention.
> But as someone w/o a lot of ORM experience, I'm wondering how these
> handle situations outside the one class/one table model --
> specifically, where you have an inheritance tree that's all based on
> the same table, and where there's a signficant amount of implicit
> self-joins. I do this now in CDBI using has_a/has_many, but have run
> into as-yet-unexplained breakdown of inheritance of triggers and such,
> which I solve with ugly workarounds.

AFAIK, neither DBIC nor RDBO do anything in particular with respect to the
various inheritance schemes. That said, any technique you use in CDBI
should be applicable in both RDBO and DBIC.

I plan to formalize one or more inheritance techniques in a future release
of RDBO. That'll basically involve adding examples to the test suite and
tutorial and maybe making a few "helper" code changes, if necessary. It
depends on what kinds of inheritance I'm going to support. I haven't
decided yet.

-John



_______________________________________________
Catalyst mailing list
Catalyst [at] lists
http://lists.rawmode.org/mailman/listinfo/catalyst


sam at vilain

Dec 1, 2005, 1:11 PM

Post #11 of 15 (13601 views)
Permalink
Re: DBIC and RDBO compared (was: Choosing the right ORM) [In reply to]

On Thu, 2005-12-01 at 08:59 -0800, Phil Mitchell wrote:
> Thanks for this great overview! You don't mention anything wrt
> inheritance of model classes -- probably it's too obvious to mention.
> But as someone w/o a lot of ORM experience, I'm wondering how these
> handle situations outside the one class/one table model --
> specifically, where you have an inheritance tree that's all based on
> the same table, and where there's a signficant amount of implicit
> self-joins. I do this now in CDBI using has_a/has_many, but have run
> into as-yet-unexplained breakdown of inheritance of triggers and such,
> which I solve with ugly workarounds.

This is a basic premise of Tangram; see Tangram::Relational::Mappings
for more information. "Triggers" are not in the model; instead you just
give your objects custom behaviour - and then Perl side inheritance
works itself out.

Sam.


kaare at jasonic

Dec 1, 2005, 8:04 PM

Post #12 of 15 (13608 views)
Permalink
Re: DBIC and RDBO compared (was: Choosing the right ORM) [In reply to]

> for thought is SELECTing things other than raw column data, using the
> RDBMS builtin functions or user-supplied stored procedures, either of

Don't know if it's a problem for any of the ORM's but some functions work
without any table.

SELECT now();
SELECT 3*sqrt(5); -- I misplaced my calculator

are perfectly valid PostgreSQL statements. Oracle has a strange 'dual' table
for things like this, but it shouldn't be necessary in modern database
systems.

--

Med venlig hilsen
Kaare Rasmussen, Jasonic

Jasonic Telefon: +45 3816 2582
Nordre Fasanvej 12
2000 Frederiksberg Email: kaare [at] jasonic

_______________________________________________
Catalyst mailing list
Catalyst [at] lists
http://lists.rawmode.org/mailman/listinfo/catalyst


kaare at jasonic

Dec 1, 2005, 9:55 PM

Post #13 of 15 (13622 views)
Permalink
Re: DBIC and RDBO compared (was: Choosing the right ORM) [In reply to]

> specific extensions like the Oracle tree stuff. With Class::DBI, you

Just a side note. The Oracle CONNECT BY is non standard, but there is a SQL
conformant tree syntax. PostgreSQL is working on it and it will show up in
psql 8.2, I guess. Other DB's might incude it later. I think that DB2 has it
already, but it's not on DBIC's target list.

> can write some hairy SQL query and let it do all the drudge work to turn
> the resulting rows into objects. This is a key feature for me.

I have a rather convoluted query builder for a system specific report writer.
I'll give rewriting it in DBIC a shot. I expect it to slow to a crawl if I
ever finish converting it, but hope to be surprised :-)

--

Med venlig hilsen
Kaare Rasmussen, Jasonic

Jasonic Telefon: +45 3816 2582
Nordre Fasanvej 12
2000 Frederiksberg Email: kaare [at] jasonic

_______________________________________________
Catalyst mailing list
Catalyst [at] lists
http://lists.rawmode.org/mailman/listinfo/catalyst


phil at 2people

Dec 2, 2005, 9:09 AM

Post #14 of 15 (13594 views)
Permalink
Re: DBIC and RDBO compared (was: Choosing the right ORM) [In reply to]

On 12/1/05, Sam Vilain <sam [at] vilain> wrote:
> On Thu, 2005-12-01 at 08:59 -0800, Phil Mitchell wrote:
> > Thanks for this great overview! You don't mention anything wrt
> > inheritance of model classes -- probably it's too obvious to mention.
> > But as someone w/o a lot of ORM experience, I'm wondering how these
> > handle situations outside the one class/one table model --
> > specifically, where you have an inheritance tree that's all based on
> > the same table, and where there's a signficant amount of implicit
> > self-joins. I do this now in CDBI using has_a/has_many, but have run
> > into as-yet-unexplained breakdown of inheritance of triggers and such,
> > which I solve with ugly workarounds.
>
> This is a basic premise of Tangram; see Tangram::Relational::Mappings for
> more information. "Triggers" are not in the model; instead you just give
> your objects custom behaviour - and then Perl side inheritance works itself
> out.

Cool! I need to look at this more ... polymorphism is exactly what i'm
wishing for in cdbi.

>
> Sam.
> _______________________________________________
> Catalyst mailing list
> Catalyst [at] lists
> http://lists.rawmode.org/mailman/listinfo/catalyst
>
>
>


--
==========================
2People Blog: http://2-people.blogspot.com/
2People site: http://www.2people.org

_______________________________________________
Catalyst mailing list
Catalyst [at] lists
http://lists.rawmode.org/mailman/listinfo/catalyst


siracusa at mindspring

Dec 2, 2005, 9:48 PM

Post #15 of 15 (13610 views)
Permalink
Re: DBIC and RDBO compared (was: Choosing the right ORM) [In reply to]

On 11/30/05 9:05 PM, Perrin Harkins wrote:
> On Wed, 2005-11-30 at 20:39 -0500, John Siracusa wrote:
>> In these situations, what I tend to do is run the custom SQL using DBI and
>> then instantiate one or more RDBO objects manually from each row.
>
> That's probably enough for most situations.
>
>> When you use CDBI to do custom queries, do you make sure that the columns
>> returned match the expectations of your CDBI class?
>
> Yes.
>
>> If so, then my commented-out get_objects_from_sql() method does the same
>> thing.
>>
> Sounds pretty similar to what I do with Class::DBI.

It's commented-out no more. RDBO 0.56 was just released:

0.56 (12.03.2005) - John Siracusa <siracusa [at] mindspring>

* Added get_objects_from_sql() and make_manager_method_from_sql()
Manager methods.
* Made the use of prepare_cached() optional everywhere. It's on
by default in Rose::DB::Object, but off by default in Manager.
Class data determines the defaults.
* Added enum column type.

-John



_______________________________________________
Catalyst mailing list
Catalyst [at] lists
http://lists.rawmode.org/mailman/listinfo/catalyst

Catalyst users RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.