Browse Prior Art Database

Persistent store for dynamic instance objects that inherit attribute/value pairs from a default object Disclosure Number: IPCOM000174673D
Original Publication Date: 2008-Sep-17
Included in the Prior Art Database: 2008-Sep-17
Document File: 4 page(s) / 40K

Publishing Venue



Instance objects are derived from object definitions. Persistent objects are defined as instance objects that will be saved so that they can be reused over the lifetime of the application, but once created do not get updated if the object definition changes. This article describes the additional capability for a persistent object to be dynamic in nature such that if the object definition changes, those changes will be reflected in the next use of the persistent object.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 40% of the total text.

Page 1 of 4

Persistent store for dynamic instance objects that inherit attribute /value pairs from a default object

Within software development, there are times when a user can create an object which contains attribute/value pairs - and use this object as the default basis for other objects. Each new instance of the object starts with the base values inherited from the default, but also can have some of the default values changed. Rather than create a static copy of the default (though modified appropriately), what is described here is the concept of dynamic inheritance of the base plus any additional modifications to the attribute/value pairs. The dynamic part of this object comes from the situation where the default object is modified after the creation of the specific instance, and the instance picks up the additional changes without any modifications to it.

While not entirely a new concept, the key here is the ability to store this dynamic object within a database (db2*, MySQL**, Oracle***, etc) for quick and complete access. Storing these objects in a database gives them permanence, persistence, and avoids accidental alteration. Static objects with attribute/value inheritance are currently stored in many different ways, one being a simple text file that can be hand edited and altered without anyone who uses the objects knowledge. Utilizing a database will give a transactional history on how a default object and other instances are modified.

What is described here is an underlying implementation for an Application Programming Interface (API) to create/retrieve persistent objects stored in a relational database.

Relational databases are pretty much the standard use of databases today. Objects tend to be the way that people naturally think, but there is not a good one-to-one mapping of relational tables to objects. This is even more true when talking about instances of objects. What is described here is the concept of a set of database tables where table A contains all the attributes/values of the default object. In rows and columns, it would be one row with a column for each attribute that the object needs defined. Additionally, default (or initial) values are stored for each attribute in the table.

A second table, table B, would contain all the instances of table A objects. This table would be composed of three columns (text) and would contain an indeterminate number of rows, The number of rows would grow as each new instance was created. Additionally, there would not be a one-to-one mapping of rows in table B to objects, but an instance object could contain multiple rows in table B depending on how many of the attribute/value pairs are overridden from the default object.

Retrieval of the instance would first require a retrieval of the default object from table A, followed by a retrieval of all the instance entries within table B and replacing any of the default attribute values retrieved from tabl...