Beefy Boxes and Bandwidth Generously Provided by pair Networks
Welcome to the Monastery
 
PerlMonks  

Re: Creating a model of a bad database

by ph713 (Pilgrim)
on Dec 12, 2006 at 17:09 UTC ( [id://589329]=note: print w/replies, xml ) Need Help??


in reply to Creating a model of a bad database

I would go the ORM route myself (but then again, I'm a pretty biased party in this discussion, as I work on DBIx::Class). You can still add custom methods and custom SQL as neccesary with DBIx::Class, and if you intend to slowly refactor the database back to sanity, the custom methods you've added to do funky things in your ORM classes serve as a sort of TODO list of things to fix.

As to the startup overhead of DBIx::Class, that is a real concern at this point, especially if your code runs in short-lived processes. Your progammer could have been talking about either or both of the following startup performance hits:

First, he could be talking about dynamic schema loading via DBIx::Class::Schema::Loader at app startup. This will always be slow, there's not too much we can do about that. On the other hand, dynamically loading the schema from the database via Loader is really only recommend for development work and/or trivial schemas. For a production application, nobody would recommend using Loader at runtime.

You can either manually define the corresponding DBIx::Class schema, or you can use DBIx::Class::Schema::Loader in "one-shot" mode to generate the schema classes on disk each time you make schema modifications in development, and then use those static classes in production.

The other startup-time performance concern is DBIx::Class's use of Class::C3 for sane multiple inheritance. Class::C3's initialization involves considerable overhead at startup time, and some minor performance overhead at runtime. This startup hit is considerably less than the Loader one above, but you'd still notice it in profiling, especially for short-lived processes.

I'm in the process of working up a patch against bleadperl to put C3 method resolution (as an optional per-package pragma) into the perl core, which is about the only sane way to improve the situation given the deep interactions with perl's method caching. I can't really offer any guarantees as to when this will be completed and/or if p5p will accept it into the canonical perl core (hopefully in time for 5.10.x?), but I'm actively working towards these goals.

-- Brandon

Replies are listed 'Best First'.
Re^2: Creating a model of a bad database
by perrin (Chancellor) on Dec 12, 2006 at 19:08 UTC
    I know DBIx::Class can handle fetching data with complex relationships. Can it handle inserts and updates that span multiple tables, without exposing the actual storage details to the user? What if they require custom SQL or custom perl processing?
      I'm guessing by that you mean insert/update to a database view, or something very like a view. DBIx::Class doesn't yet do that, and I don't know that it ever will. In PostgreSQL you can only do it by defining custom rules for the view AFAIK. I haven't had any personal experience with a database that does it with no extra work, if there are any. Topics like this have been discussed on irc.perl.org #dbix-class before, but implementing them in the generic case is tricky at best.

      Along these kinds of lines, the best we could offer at the moment is that you can make a ResultSource class for view just like you could for a table (if your database doesn't support real views, that can be hacked as well, by basically specifying the SQL that generates the view as the table name, IIRC), and then you could override the update and insert methods for this source and include your own custom code that breaks out the data and does the insert/update to the underlying tables (either using DBIC abstractions of those tables, or raw sql via a dbh accessor).

        The custom ResultSource doesn't sound too bad. The reason I ask is that it sounds like that's what Ovid will need here, with a database schema that he wants to abstract away. Otherwise, he'd have to make his API deal with the actual tables as they currently are.

        I haven't used DBIx::Class or another ORM module (this is long due actually...) but from a model perpective views are usually to drive queries. Inserts or Updates on views will be in general very database-dependent or even not supported (or via custom-made procedures that usually defeat the use of an ORM)

        Am I missing something?

        hth --stephan
      I was thinking if it might be possible to handle inserts and updates to related tables with triggers. Since you'll have the columns of the other tables defined in this object anyway (in a TEMP column group), that should be relatively painless.

        If you have groups of related tables, you can present a view and then use triggers to handle inserts and updates spanning multiple tables in the view. Well, you could, but MySQL's views are broken and don't allow you to attach rules or triggers to them (I hear this may change soon, but I'm not sure). Both Postgres and SQLite handle this correctly.

        Cheers,
        Ovid

        New address of my CGI Course.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://589329]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others lurking in the Monastery: (3)
As of 2024-04-24 02:39 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found