| Home >> All >> com >> jcorporate >> expresso >> core >> [ dataobjects Javadoc ] |
| • | com.jcorporate.expresso.core.dataobjects.jdbc.* (16) | • | com.jcorporate.expresso.core.dataobjects.jdbc.tests.* (3) |
| • | com.jcorporate.expresso.core.dataobjects.test.* (2) |
• com.jcorporate.expresso.core.dataobjects: Javadoc index of package com.jcorporate.expresso.core.dataobjects.
Package Samples:
• com.jcorporate.expresso.core.dataobjects.jdbc: The DataObjects package contains a set of interfaces and base classes that give the ability to provide a unified object approach to various data sources.
• com.jcorporate.expresso.core.dataobjects.test
• com.jcorporate.expresso.core.dataobjects.jdbc.tests
Classes:
• FieldRangeParser: The responsibilities of this class is to verify range values for fields and throw an exception if there is any 'monkeybusiness' detected in the field. The parser does not allow everything a normal SQL query would allows due to parsing complexity. However, it will allow multiple conditions, and ranges for BETWEEN and IN. Accepted Range Strings: [NOT] BETWEEN value1 AND value2 [NOT] IN(value1,value2.....) [>|>=| |>=| Known bugs with Range issues: There can be no single quotes INSIDE string fields. The fields themselves must still be quoted. There cannot be the word AND or OR inside the String range ...
• Securable: Interface to described a database object that is subject to security constraints. Expresso treats instances of Securable as something that can be checked on a state by state basis. Expresso uses a global setup value to determine whether non-Securable DBObjects can be granted user access through items such as DBMaint. All classed derived from com.jcorporate.expresso.core.dbobj.SecuredDBObject automatically implement the Securable interface Typical Usage: Securable s = new com.jcorporate.expresso.services.dbobj.MimeTypes(); s.setRequestingUid(request.getUid()); try { s.isAllowed("S"); System.out.println("User ...
• DataTransferObject: Basic HashMap wrapper for the Data Transfer Object pattern. The goal of this class is to provide efficient serialization over the wire of DBOBjects and or the up and coming DataObjects. By encapsulating the 'data guts' of the data objects into this class, routing programs that don't have to know anything about a particular instance of a DBObject/DataObject don't have to have any large code base installed on them. The other advantage of DataTransferObject is serialization size. On tests conducted 3/17/04, the size of com.jcorporate.expresso.services.dbobj.MimeTypes was 1310 bytes. The size of the ...
• JoinedDataObject: DataObject for use with 1:1 joins between database objects. This class provides a multi-dbobject view of the underlying databases. It is similar to MultiDBObject in that it joins several JDBC-based dataobjects together. The biggest differences are: XML-defined joins. Use XML definitions in your classpath to define the joins. In accordance with jdbc-join_5_1.dtd DBMaint compatible. By refactoring DBMaint so that it is DataObject aware rather than DBObject aware, we gain the ability to manipulate/update the joins in DBMaint directly rather than making readonly database joins. Limitation: Although ...
• LobField: This class provides a low level BLOB capability while still keeping the programmer isolated from SQL syntax details. The general usage is as follows: MyDBObject myObj.setField("key1",1); LobField query = new LobField(); query.setCriteria(myObj); java.io.InputStream inputStream = getBlobStream("blobFieldName"); //Do whatever you want with the stream inputStream.flush(); inputStream.close(); query.close(); This class requires a JDBC 2 compliant driver for the BLOB/CLOB data types. Some drivers do not support these features, at which point you'll ...
• NestableDataObject: Nestable indicates that the derived class includes nested data objects. While the dataobject 'cluster' should be able to be acted on as a single unit, once in a while, it is necessary to get at the internal or "nested" data objects. An example of the Nestable usage is in com.jcorporate.expresso.services.controller.dbmaint.ViewBlob in conjunction with a com.jcorporate.expresso.cores.dataobjects.jdbc.JoinedDataObject . The ViewBlob routine needs to get to the low-level JDBC data objects rather than operate on the join as a whole. Since JoinedDataObject implements the Nestable interface. ...
• DataObject: This interface represents the basic needs of a dataobject, namely to add, update and delete itself, set it's own fields, and deal with things accordingly It is currently considered BETA code at this time. It's intention is to provide a refactoring launching point. Until then it is recommended that by and large you use the DBObject class directly unless there is a specific feature that the DataObject interface provides that you need. However, be forewarned that the interface will change. For example, Exceptions will eventually be refactored from DBExceptions to DataExceptions.
• JDBCExecutor: Initial separation of DBObjects from the underlying JDBC code that gets executed. This is part number 1 where we move a lot of the JDBC code over to this helper class. For round #1 iteration, we're assuming that the valueObject is actually a DBObject that implements the DataObject interface (which it does). This is because we're interested in getting something working and demonstratable, and then slowly flesh out the DataObject interface so that we can eventually completely prune this class completely away from the DBObject class and work strictly with the DataObject Interface.
• DataObjectMetaData: This interface contains the "definition" of the DBObject, while the DBObject itself contains only the data itself. One DBObjectDef object is stored in a static HashMap in the DBObject class, and is looked up and referenced for all definitions of the structure of the given object. since this class is not threadsafe for adding information, it is imperitive that all information addition, typically done when the first instance of a DBObject is instantiated, is done in a synchronized context.
• SynchronizedDataObject: This class provides a threadsafe access to a dataobject. To be able to more safely share your dataobjects acrossed multiple threads, simple call. Typical Usage: DataObject myobj = SynchronizedDataObject.newInstance(new MimeTypes(SecuredDBObject.SYSTEM_ACCOUNT)); //We now have a wrapped MimeTypes data object myobj.setField("MimeNumber",new Integer(1)); //Retrieves a set of cloned records. ArrayList records = myobj.searchAndRetrieveList();
• Defineable: Interface for providing auto-definition of DataObjects. Many DataObjects needs something other than just classname to differentiate themselves. For example, AutoDBObject needs to know the table name to automatically initialize to. JoinedDataObject needs a location of the xml definition file. Classes that implement the Defineable interface should get their setDefinitionName() called before the object is actually used in any manner.
• DataExecutorInterface: This class' job is to provide an interface between DataObjects and the underlying data source. It provides the actual execution. By separating the logic, we gain the ability to do things such as have the actual Execution take place on another machine. Just write an executor facade and be done with it.
• Mappable: Objects that implement this interface are claiming that there is a one-to-one relation between one field value and a key field value. A classic example of this in Expresso is the fact that a ExpUid maps one to one to the LoginName. This helps guarantee that lookup objects can map to a specific value.
• DataFieldMetaData: This interface will eventually have the same public functionality as DBField . It is just used as "Interface"e; glue right now. It will be fleshed out significantly in future versions. This interface represents the descriptive data for a particular DataField.
• JoinedDataObjectMetaData: Not yet released - do not use in your own code yet. This object provides an implementation of DataObjectMetaData that is used for the various join operations. It's job is to provide the descriptive services required for applications such as DBMaint to generically access the JoinedDataObject.
• DataQueryInterface: This interface provides a standard interface to deal with parts that operate and return multiple DataObjects. This is in an attempt to make a DataObject more focused than before. [ie to cut down on size] by separating operations on a single dbobject from operations on a multiple dbobject.
• ContextNested: Context nested represents any object that can be retrieved or set to any specific data context. The classic example of this is the DBObject where we call setDataContext() with every instantiation. Other examples include c.j.e.core.security.User
• DataObjectFactory: Constructs 'often' DataObjects based upon standard order of initialization and the interfaces it implements. For example, Defineable objects must have setDefinition() called first, then setDataContext(), then setUid()
• JDBCObjectMetaData: DataObject Metadata that is specific to JDBC implementations only. For example, TableName is absolutely meaningless in a non-JDBC environment. The DBObject metadata is derived from this interface
• DataException: Base class exception for the dataobjects framework. It is currently derived from DBException to allow for merging between the two distinct frameworks. The old DBObjects and the new DataObjects
• DefaultDataField: Default implementation of the DataField interface. This class provides some basic conversion capabilities between different Java types as well as provides all use change logging capabilities.
• JDBCUtil: This class provides utility functions that are common across the jdbc.* package classes. This class is normally not accessed except through other classes in the jdbc package.
• PersistenceManager: This is the persistence manager class. It currently contains a type mapper and a configuration engine. Other components such as Transaction Manager, etc are to be added at later dates.
• JoinedDigesterBean: Not yet released - do not use in your own code yet. This class provides the Digester information to parse the join definitions so that we can define the join definition in an XML file.
• DataField: This class represents a single field of data that is stored within the data object. It will provide basic manipulations such as it's original value, and attribute holdings.
| Home | Contact Us | Privacy Policy | Terms of Service |