As you might recall near the beginning of the chapter, Expresso is in the midst of abstracting services common to DBObjects into a series of interfaces that provide for generic access to multiple data source types. JoinedDataObject is an example of the results of this effort.

JoinedDataObject is very similar to MultiDBObject except that it was a ground up rewrite for efficiency, as well as its goal is to act to a client programmer just like a standard DataObject. While the convenience services available to DBObjects are often not available, the DataObject API is no less powerful. After all, DBMaint can accept any object that implements the DataObject interface for management. By extension, DBMaint can then manager a JoinedDataObject just like any other DBObject.

JoinedDataObject UML

For those that are proficient in understanding UML, a UML diagram describing the JoinedDataObject class has been included here. The details won't be gone into here, but remember that it simply uses the same interfaces that have been defined earlier in the other UML diagrams. The implementation is just different.

Since Expresso 5.1, DBMaint has been rewritten to manage any DataObject, whether it is backed by a database or an in-memory hashmap. So, of course, DBMaint can now handle displaying and managing JoinedDataObjects.

Traditionally, you launch DBMaint with the 'dbobj' parameter telling it what class to instantiate and use. But of course, JoinedDataObjects use the 'Defineable' interface to uniquely retrieve their definition. To this end, the 'definition' parameter has been added to DBMaint's capability. The definition parameter is identical to that of what you set earlier when instantiating it by memory. So to list all records of the join, enter (all in one line)

/DBMaint.do?dbobj=com.jcorporate.expresso.core.dataobjects.jdbc.JoinedDataObject&definition=
/org/example/myapp/dbobj/myjoin.xml&state=List

Normally, JoinedDataObject checks the security of all dbobjects involved and takes the most negative result. In other words, a security check in a JoinedDataObject only returns true if access is granted for all the joined objects.

However, sometimes you flat don't want certain actions available to the client. An example of this might be the 'Add' action. Sometimes adds on a join can be extremely fickle. While JoinedDataobject first adds the rightmost object (the last data object defined in the xml file) and then works to the left (the first data object defined in the xml file), sometimes it's too likely that the end user will muck up the relations. So Expresso provides a feature to allow you to turn off the create/read/update/delete capabilities in an override fashion. To do this, you add a new element to your join definition file called 'permissions'. An example is like so:

<dataobject-join description="Download Log View">
  <dataobject className="com.jcorporate.expresso.ext.dbobj.DownloadLog" alias="DownloadLog"/>
  <dataobject className="com.jcorporate.expresso.ext.dbobj.DownloadFiles" alias="DownloadFiles"/>
  <dataobject className="com.jcorporate.expresso.services.dbobj.MimeTypes" alias="MimeTypes"/>
  <distinct distinctJoin="true"/>
  <permissions add="false" read="true" update="true" delete="false"/>
                 .....

Take a look at the permissions line. In this case, we never want to allow an 'add' or 'delete' through this join. But don't mind allowing updates or reads. In short, we want this particular join to allow easy browsing of the underlying database tables, but not allow the user to seriously modify the underlying data. (In 'update', the user is not allowed to modify the foreign keys in an object, so referential integrity will not be destroyed)

Question: I'm trying to make a JoinedDataObject within RowSecuredDBObject.searchAndRetrieveList() which will help do security checks w/i DB, rather than as N tests after getting the list. But RowSecuredDBObject is the superclass. The real join is on the subclass. In MultiDBObject, I can use getInstance(), but in the XML for JoinedDataObject, I think I'm out of luck.

Answer: You can provide a populated JoinedDigesterBean instance that is built on the fly that gives you the query capabilities:

JoinedDigesterBean bean = new JoinedDigesterBean();
bean.setName("RowPermissions/" + this.getClass().getName());
bean.addDataObject(this.getClass().getName(),null,"class1");
bean.addDataObject(myClassTwo, null,"class2");
bean.addRelation(....  [API mirrors XML]);

JoinedDataObject jdo = new JoinedDataObject(bean, "RowPermissions/" +
                        this.getClass().getName());

Because it's expensive to initialize metadata, each ad-hoc join will need a distinct name since the metadata is cached. However, after the initial build, then you get:

JoinedDataObject jdo = new JoinedDataObject("RowPermissions/" +
                            this.getClass().getName());

And you will get a JoinedDataObject with the definition previously defined.

[Begin API Dreaming] In reality, what is really needed is a "JoinedDigesterBean Builder" in the form of a query specification object. It would be similar, but less powerful than the Hibernate "Criteria" API. Off the top of my head pseudocode:

QueryObject query = dataObject.buildQuery();

query = query.criteria(example(dbobject1)
            .and(example(dbobject2))
            .and(example(dbobject3)));
query = query.firstRow(30).numRows(60);



query = query.criteria(
            field(DBObject1.class,"fieldName",value)
                .and(DBObject2.class,"fieldName2", value2));


// etc.

//Make implementation of List a 'lazy list' that keeps returning
//values until end of Recordset or until
//query.close() is called
try {
    List result = query.execute();
    for (Iterator i = result.iterator(); i.hasNext();) {
        DataObject eachObject = (
        ....
    }
} finally {
    query.close();
}

Now, I think the only real problem with the above is that I don't think we embed enough relationship metadata within DBObjects to have the dataobject API automatically navigate the relations. So DataObject API metadata may need some steroids. :)

Creating a MediaDBObject basically two steps: to start with, derive your class from com.jcorporate.expresso.services.dbobj.MediaDBObject. Secondly, instead of calling addField() in your setupFields function, you call addBlobField() instead.

A concrete example:

public void setupFields() throws DBException {
    setTargetTable("TESTMEDIA");
    setDescription("Blob Storage Test");
    setCharset("ISO-8859-1");
    addField("TestKey", "auto-inc", 0, false, "Test Table Key");
    this.addBlobField("Data", "Sample Media Field");
    addKey("TestKey");
}

The crux of the above code is the addBlobField(). In reality all it does is create three additional read-only fields for each file. You do not have to worry about these fields yourself as MediaDBObject uses and sets them automatically for proper BLOB bookkeeping. You CAN reference the fields if you so wish for your own programming needs.

You can save your BLOB fields in the following example code:

// Open the file, get its length
File f = new File(importFile);
InputStream is = new FileInputStream(f);
int fileSize = (int) f.length();

// Create an instance of your media dbobject.
MyMediaObject myObj = new MyMediaDBObject(Securable.SYSTEM_ACCOUNT);
myObj.setDataContext("default");

// Add the dbobject with key == 1
myObj.setField("key", 1");
myObj.add();

// Now we save the BLOB fields in a different 'statement'.
myObj.saveBlob("Data", is, importFile, fileSize);

The code to retrieve the BLOB is similar:

// Open the file, get its length
File f = new File(exportFile);
OutputStream os = new FileOutputStream(f);

// Create an instance of your media dbobject.
MyMediaObject myObj = new MyMediaDBObject(Securable.SYSTEM_ACCOUNT);
myObj.setDataContext("default");

// Load the dbobject with key == 1
myObj.setField("key", 1");
myObj.retrieve();

// Now we retrieve the BLOB fields in a different 'statement'.
InputStream is = myObj.retrieveBlob("Data");

//
// The following code is basically the fastest way to read an input
// stream and copy it to an output stream.  Error checking for
// flush and close() have been removed.
//
byte[] buf = new byte[4096]; // 4K buffer
int bytesRead;

while ((bytesRead = is.read(buf)) != -1) {
    os.write(buf, 0, bytesRead);
}

os.flush();
os.close();

Ok, so that may not appear to be the easiest way of dealing with it. How about if we look at DBMaint? If you haven't encountered DBMaint already, you soon will. It is saturated throughout Expresso for maintaining database tables. It has search/add/update/delete capabilities and if you take the time to add a custom UI, can save you buckets of coding time for webapp management controllers.

If you use the URL with something like:

http://localhost:8080/DBMaint.do?state=Add&dbobj=org.example.dbobj.MyMediaDBObject

DataObject sharedObject = SynchronizedDataObject.newInstance(mydbobj);

The concept is simple, pass the newInstance method an already instantiated instance of a non-threadsafe DBObject or DataObject, and it will wrap that object in a threadsafe manner. You can use the threadsafe dataobject in the same way you could use any other DataObject. The API is conformed to.

The following persons have contributed their time to this chapter:

Copyright © 2001-2004 Jcorporate Ltd. All rights reserved.