use Perl

• Decomposition (Score:1)

  by chromatic (983)

  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
  • Re:Decomposition (Score:2)

    by Ovid (2709)

    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,
    • Re:Decomposition (Score:2)

      by autarch (914)

      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).
      • Re:Decomposition (Score:2)

        by Ovid (2709)

        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
        • Re:Decomposition (Score:2)

          by autarch (914)

          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?
          • Re:Decomposition (Score:2)

            by Ovid (2709) on 2002.12.12 15:19 (#15379) Homepage Journal

            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_region_id globalRegionID
              name localRegionName
              description description
              phone enquiry_phone
              fax enquiry_fax
              email enquiry_email
              display enquiry_display
            /);

            You'll note that over the course of time, we've managed to have some field names that are studly caps and others that use underscores. Further, two of the field names have the table name embedded in them (whether or not that is a good thing is a matter of debate). However, the keys here are used to generate nice, consistent method names. I don't have to worry about what it's called internally. Further, if we go back and fix all of the field names to be more consisten, very little of the code changes except for the values in the mapping. In this case, it's not the meaning that has changed, but merely applying a more consistent style.

            my %map = ( qw/
              id id
              global_region_id global_region_id
              name name
              description description
              phone enquiry_phone
              fax enquiry_fax
              email enquiry_email
              display display
            /);

            This is useful because it makes the code more robust. I feel that it's very important to force this decoupling of method names from field names. Further, if the meaning does change and I have to alter the method names, this is not more work than it would be otherwise. It should also be added that I didn't notice Class::DBI when I was checking out the POOP modules. Funny thing, that.

            Reply to This

            Parent