ObjectRowMap ObjectRowMap is a simple Perl object to DBI persistence engine.
Download

ObjectRowMap Ranking & Summary

ObjectRowMap Tags

Perl module perl object DBI Perl object DBI persistence engine

ObjectRowMap Description

ObjectRowMap is a simple Perl object to DBI persistence engine. ObjectRowMap is a simple Perl object to DBI persistence engine.ObjectRowMap is a Perl module which works with the DBI module to provide a simple means to store a customized style of perl objects to anything with a DBI module and generally SQL 92 (or later) syntax.Basic UsageObjectRowMap must be inherited from to be of use, attempting to use it directly will not have the desired effect, whatever that might be. Create instances of your inheriting class.1. Required - Create a new class which uses and inherits from Object Row Mapuse vars qw( @ISA ); use ObjectRowMap; push @ISA, 'ObjectRowMap';2. Required - Define a method called ormapProperties() in your new class to control the behaviour of ObjectRowMapThere are a lot of clever things you could do here to handle connection pooling, obtaining database passwords, whatever is your pleasure. At the end of all that, you have to return a hash with the following (some portions are optional)Elements are flagged "req - required, reqor - required or, op - optional" in the list below: 'required' means just that, 'required or' means that it or the next (previous) is required (should be clear), 'optional' means just that (default provided){ 'table'=>'tablename','keyFields'=>,'usePrepareCached'=>'0 or 1, do I use prepare_cache instead of prepare, (op) (def 0)','dbhConnectArgs'=>,'dbh'=>'existing dbh (reqor)','persistFields'=>{'hash'=>'of','fields'=>'to','persist'=>'and','initial'=>'values,'(req)'=>''},'debug'=>1,'commitOnSave'=>1 }Simple Example:sub ormapProperties { return { 'table'=>'ormtester','keyFields'=>,'dbhConnectArgs'=>,'persistFields'=>{'login'=>'','uid'=>'','password'=>'','gecos'=>''},'debug'=>1,'commitOnSave'=>1}; }Some Explanation where it might be helpful- dbh - if you are handling your own dbh, put it here and don't bother with dbhConnectArgs keyFields - the fields which inidividually or together define a unique instance dhbConnectArgs - if you don't handle your own dbh connection, you can just return exactly the arguments you would have sent to DBI::connect and it will do it for you. It maintains a single dbh per persistent class, in this case, do not define a dbh persistFields - a hash of the fields you wish to persist and their initial values, you must also define key fields here. Instances of will automatically handle get and set for these (see below) debug - if true, you'll see the sql which will be executed commitOnSave - if true ObjectRowMap calls commit() at the end of save(). You can handle your own transactions if you passed in your own dbh. If you want to do this you will want to make this false. Otherwise it should be true or save will do you little good...3. External Requirements - setup your database (or other dbi source) and get the connection going. The column names that you care about must have the same names as your entries in 'persistFields'You are now done with the required components4. How it will work:Create a brand new never before seen instance and persist it:my $orm = new ObjectRowMap::Test(); $orm->set('login'=>'me'); $orm->set('gecos'=>'Myself'); $orm->set('uid'=>1); $orm->set('password'=>'mypass'); print $orm->get('gecos')."n"; $orm->save();Load an existing instance, and just get info from it:my $orm = new OrmTester(); $orm->set('login'=>'me'); $orm->load(); print $orm->get('gecos')."n";Load an existing instance, change, and update it:my $orm = new OrmTester(); $orm->set('login'=>'me'); $orm->load(); $orm->set('gecos'=>'StillMe'); $orm->set('password'=>'mynewpass'); $orm->save();Load an existing instance and delete it:my $orm = new OrmTester(); $orm->set('login'=>'me'); $orm->load(); $orm->delete();Additional Explanation and some advanced topicsAll of these are object methods (including the ones which return multiple other objects - this is because of how ObjectRowMap handles things internally...) The only class method is 'new'load() - loads rest of object if "enough" values (e.g. key values) already set save() - smart update of database from object, or inserts a new object (only changed fields) loadFromHash() = for efficient loads from database with your own external query, mostely for internal use by allAsList and listFromQuery, no load from database will occur, all fields better be defined (very "raw") allAsList() returns all instances of an object as an array (think about it, could be bad if you have a million records. May build a more sophistocated iteration based possiblity later. For working with "groups" of objects, see "listFromQuery") listFromQuery() you provide the query, I provide the list of objects. The order and contents of the field part of the select are VERY important, you should use postSelectFieldString to get the query portion which follows the "SELECT" in your custom query postSelectFieldString() - see listFromQuery aboveYou can intercept a get or set for any field by defining YourPackage::get_fieldname() or YourPackage::set_fieldname(). This means your callers would still simply use $orm->set() and $orm->get() just like otherwise, but your "special" interceptor will be detected and called. The idea is that you can just drop in (or out) an interceptor without having to either change client code or define an accessor method for each field. How these work is a little asymmetric (like get and set themselves)- $orm->set('field'=>'value') - YourPackage::set_fieldname() is called with ('value'), whatever you RETURN is stored in the correct place and success (1) is returned to the caller (you can do more storing of your own if you wish, of course, and ignore this - it's for convenience) $orm->get('field') - YourPackage::get_fieldname() is called with the value which would have been stored by a previous set (whether you override set or not is immaterial) and what you RETURN is returned to the caller. Again, you are free to ignore this and just store things whever you want - since only $self->{'ormap'} is reserved, you have plenty of name space.pre-database processing for a field can be done by providing YourPackage::preSave_fieldname() (what you return is inserted instead of the actual field value, the actual field value is not modified in the process (unless you do it, of course)), YourPackage::postLoad_fieldname() will be called after a load with the raw database value (the field is not set before or after the call if you define this, it is up to you if you define it) - these are useful for pre and post processing related to special storage in database, things like encryption of values in the database, binary ip address storeage, date formats (some examples in ObjectRowMap::Test)You can use get and set for any non-persistant fields you desire and they are stored and saved the same as the persistent fields (the set_fieldname and get_fieldname interceptors will also work) - the only thing is that there is presently no automatic initialization during construction so you would have to do that yourself (and see the caveat below about overriding the default constructor) (and, of course, such fields are ignored during load and save, but then, that's what you want or you would make them persistent fields...)Of course, other than the methods discussed above and those below in Caveats, you can define your own methods. Actual values are not stored at the top of the self hash and where they are is an implementation detail which may change, so you should use $self->get() and $self->set() just like your callersA word about keys - an update will fail if at least one key for the object has not remained unchanged since the last load (for the where clause) (as it should... otherwise you would "miss" your instance's row and/or (if no keys defined) "hit" every row in the database (peek at how save builds the where clause if this doesn't make sense)). This also means that you cannot change all keys with a single load/set/save sequence - you will have to save between changing each key. You must define enough of your keys to achieve uniqueness before a load, otherwise you just get the first row returned. It supports multiple keys but has no idea how many are required for uniqueness, it will use all that it has which are defined (you can initialize them to undef to make full use of this behaviour)...DBI/DBD/Database compatibilityUses a minimal portion of SQL 92, should work with practically any DBD module which correctly implements 'ping', it's been tested with mysql and postgress, but I can't imagine why it would not work with nearly anythingCaveats and LimitationsYou must call $self->ObjectRowMap::init() at construction if you override default constructor. At present the contructor ignores anything you may pass to it. $self->{'ormap'} is a reserved element of the self hash YourClass->ormapMeta{} is a reserved class level variableset and get only work for one field and field/value respectively. This is to keep things as relatively clean and efficient as they aredon't define methods for load, save, loadFromHash, allAsList, listFromQuery or clearChanged unless you have read the code and know what you are doingInstances are not thread synchronized and if you simply provide connection strings for ObjectRowMap to create database handles, it will only use one per class. This means that in a multi-threaded implementation there could be a problem with multiple threads using the same dbh at the same time. If you synchronize access by class or handle your database handles yourself in a threadsafe way you should be OK. It would not be hard to make it threadsafe by default, I may at some point. If you are really paranoid, you would want a semaphore per object and override/lock for all "set's", if you are just smartly-cautious all you have to worry about is synchronization of database handles.It's really simple. This is a caveat and a limitation. It's been extremely useful to me but since it doesn't handle multiple-table objects or anything but 1:1 relationships (automatically, that is, you could do some things on your own within it's framework to accomplish that...), it will require more work on your part to handle these more complex things. I wrote it in a few hours after having re-written similar custom functionality over and over on a project and found it was just fine for my needs so I never extended it - feel free, or you can ask for specific additions or my thoughts on them - I've got a plan for more complex objects, but haven't written code for it Requirements: · Perl

ObjectRowMap Related Software