Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

Ovid (2709)

Ovid
  (email not shown publicly)
http://publius-ovidius.livejournal.com/
AOL IM: ovidperl (Add Buddy, Send Message)

Stuff with the Perl Foundation. A couple of patches in the Perl core. A few CPAN modules. That about sums it up.

Journal of Ovid (2709)

Thursday December 05, 2002
05:49 PM

New Territory

[ #9297 ]

As part of a refactoring effort with one of our projects, I've started to create persistent objects that map to a single row in a database table. It's been a lot of fun, but I've run into a weird problem with a potentially weirder solution. If I instantiate a "people" object, I can get the company id, but not the company. So I use the company id to instantiate a company object. Which has a state/province id, which leads to a country id, which in turn leads to a global region id. So, I find that I need to instantiate five objects to get the following line displayed:

Tommy Atkins, Foo Company, Poole, United Kingdom, Europe

With, at present, 387 people in the database, that's 1935 objects that I need to instantiate to merely get the name of each. There's a noticeable delay in instantiating the list of 387 people, so this will not scale.

My thought has been to create views in the database with the data that I need for given diplays and possibly reuse this data for multiple diplays. Then, because updating a view can be difficult (there is some support for this in MS SQL Server), I use a feature that I built into my objects, but hadn't actually used. When I create a "View" object, my constructor uses the following:

$self->_set_read_only;

It's very nice and simple programming everything this way, so I've been having a lot of fun. Further, because of some of the things that I've read here, the following works:

$people->set_fields( $people->get_fields );

As does the following:

$people
  ->new( $id )
  ->set_first_name( $first )
  ->set_last_name( $last )
  ->save;

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • I wonder if mapping objects to records is working in this case. This is just brainstorming, so ignore me if lighting doesn't strike.

    One random thought is that you could have something that maps bits of SQL and objects that contain these bits of SQL, turning them into full-blown queries only when it's necessary to pull a row. For example, you'd set constraints such as associated with this person's name and matches the previous constraint's office_id field, passing that to a method that builds the appro

    • Can you give an example? It seems that having objects that contain bits of SQL and then trying to put all of that together is a daunting task. My underlying structure seems sound and it has worked wonderfully. All I do (mostly) is subclass a PersistentObject class, provide some class data and I have 20 to 30 methods instantly built for only about 5 minutes of work. Previously, I was trying to do all of that by hand for each "thing" in the database and it was an absolute nightmare. This is much faster,

      • Sounds like you've partially rewritten Class::DBI and/or Alzabo, both of which are designed to let you represent database rows as objects (Alzabo also does some other neat things too).
        • Alzabo doesn't support MS SQL Server, which is what I am running on. I had checked out some of the Perl OO Persistence work, but most of it had one or more of the following limitations:

          • Doesn't support MS SQL Server
          • Doesn't support an existing schema
          • Poor documentation
          • No longer maintained

          Tangram [soundobjectlogic.com] looked interesting, but from what I could tell, gradual refactoring wasn't an option as it appears to go from the object to the schema. Existing schemas meant I was out of luck.

          I'm going to grab A

          • Of the four problems you cite, Class::DBI doesn't have any of them, and Alzabo just doesn't support MS SQL server. Adding support for it wouldn't be too hard, however.

            I disagree about decoupling mtehod names from column names, however. If it changes in the schema, that probably means that the _meaning_ has changed, so why not change the method name?
            • It might change the meaning, but it also might be a relatively trivial change that shouldn't affect the overall design of things. For example, with my code, the programmer must explicitly provide class data that maps external names (used in methods), to field names in the database. Here's a map for our "local regions" (note that the field names are not aligned because of difficulties formatting one use.perl). I want <pre> tags :)

              my %map = ( qw/
                id localRegionID
                global_reg

  • > With, at present, 387 people in the database, that's 1935 objects that I need to instantiate...

    I hope you're not fetching every bit of data from the database 387 times. You should only have to fetch each unique thing once using something like the Memoize module or some homegrown version of it. If you don't have 387 global regions, then you shouldn't have 387 instances of them.

    • I'm not using Memoize. Instead, I check the id and classname and if I already have an instance of an object, I fetch it from a cache. Because it's only a reference in the cache, all instances of the object are simultaneously updated (if more than one) and I don't typically need to worry about database synchronization issues.

      In other words, my initial explanation was a bit simplistic, but it seemed easier that way :)

      • Most people use a "if it's not in the cache, fetch it" strategy. An alternative is to fetch the data, and only add it to the cache if it's not already there. This sounds counterintuitive, but can be a win if can fetch data for the complete traversal of objects in one query. That is, instead of having the Person class do a query to get a person by id, have a helper class use a JOIN query to get the person data (by id), along with the company data, along with whatever else, in one big row. Then pick the row a
  • Keep in mind that I only get to read what you post, and the general uselessness of "Can't you just..." [perl.org].

    A couple of people have already mentioned Memoize, which return the same result given the same input. The same result can be the same object. A given company (or whatever the appropriate thing), you can return the same object. This has shades of the Flyweight Design Pattern (note: this is not the same "flyweight" concept that Damian discusses in his book). Keep a collection (the flyweight pool) of obj