All the Perl that's Practical to Extract and Report

Navigation

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Without JavaScript enabled, you might want to
use the classic discussion system instead. If you login, you can remember this preference.

Please Log In to Continue

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, but I've traded away flexibility for simplicity.

I should add that I had considered adding some data to each class that would map out possible connections to other tables and dynamically build complicated queries depending upon the data that I needed, but once I sat down and saw how far I would have to go to implement that, it didn't seem feasible. On the other hand, I've often found that things that aren't feasible tend to be much easier once I just byte (sic) the bullet.

I don't think lazily-instantiated objects is the key, either (assuming we're thinking the same thing). In this case, when I create a list, I still need to instantiate every one of those objects just for the name. If I don't istantiate them up front (a huge chunk of memory), then I need to instantiate them as I go ensure they get reaped ASAP. That would be less memory, but even if that doesn't take longer, it will still be at least as long as it was, thus putting me back to my original performance problem. If you think I'm missing the point, let me know.

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.

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:)