You will have to perform your queries a little different to take this into account. One way (I do something along similiar lines but far more expansive, I don't even know castor exists in my applications)
MyInterface{
String getCastorQueryPrefix();//methods exposed to developers }
MyImpl implements MyInterface{
String getCastorQueryPrefix(){
//should cache this in a static member as only needs to be created once
return "SELECT " + getPrimaryKeyName() + " FROM " + this.getClass().getName() + " WHERE ";
}
//interface methods
//methods to make castor work
}
And you would use it like:
db = getDatabase(); ... OQLQuery oql = db.getOQLQuery( myImpl.getCastorQueryPrefix() + " foobar=$ ); ....
You would most likely put all object creation in an instance creation class:
MyObjectFactory{
public static MyInterface newMyInterface(){
return new MyImpl();
}
//other interface-->impl methods
}You could also put the prefix query creation in the factory class.
The advantage you have with this way of doing it is that now you seperate out the implementation from the interface so if you make changes in the implementation than the rest of your codebase should be minimally affected, along with allowing you to configure your db object prior to handing out to the application. You could also have different implementations for different databases if required, in which case you probably want to make your object factory configurable with a properties file (interface-->impl).
That's my take on it,
-Bert van Brakel
Gregory Block wrote:
On 29 Jan 2004, at 02:53, Jeremy Haile wrote:
However, the configuration utility needs to be able to set the ID
property so that our persistence mechanism (Hibernate) knows that the
object already exists. I think this example could be applied to a lot of
examples in large applications where a value is almost always only
modified internally, but where the XML "serialization" process requires
the property to be set by an external class (Castor).
Indeed; this is one of those difficult areas where, for all intents and purposes, any user of said API should consider it an implementation detail, but marking it private makes it impossible to set; while it's possible to instantiate public objects from private representations pulled from castor, this essentially doubles the amount of required work just so you can protect an API from users; when all one would *really* need would be for Castor itself to permit itself to use those private (or, hell, even protected would be a good limitation) fields and methods to set that data.
It also ends up holding true when the data, provided in one form from the XML source, needs to be modified on write to conform to a better object/data model for use in the application; in this case, private API provides the XML read/write activity for the given format, but the public API intended to be used by end-users in the application uses a public API. Folks who end up using XML generated by MS SQL often run into times where these XML feeds have "t", "Y", or even "X" when what they *meant* was a boolean "true"; while it's possible to write field accessors to make up for these shortcomings of the data source, the easiest way is through read/writing to private API on the object.
----------------------------------------------------------- If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
unsubscribe castor-dev
