Scott T., I would like to modify the SelectionCriteria
class along the lines I dicussed with you earlier.
My suggestion is that the class have only two members,
as in Scott's paper:
protected String attributeName;
protected Object value;
The constructor takes these two guys. The subclasses
simply super().
Please note that I'm using SqlInterface as the class
for building the strings. It's providing that portion
of the functionality of Scott's
RelationalDatabase class.
Now asSqlClause would take ClassMap as an argument so
we have:
AttributeMap map =
classMap.getAttributeMap(attributeName);
String valueString = null;
// For columns
if (value instanceof AttributeMap)
valueString =
((AttributeMap)value).getColumnName();
else
valueString =
classMap.getSqlInterface().asSqlValue(value);
// To allow formatting each column individually use:
// valueString = map.asSqlValue(value);
return new String(map.getColumnName() +
relationalOperator(classMap.getSqlInterface()) +
valueString);
Now, implementing, say CriteriaEqualTo is trival.
It's just:
public String relationalOperator(SqlInterface
sqlInterface)
{
return sqlInterface.getClauseStringEqualTo();
}
This also entails changes to PersistentCriteria. Why
not just three members?
Vector criteria = new Vector();
protected String forClass;
// protected boolean areSubsIncluded;
I used String for forClass because I don't see need
for class.
Vector just holds all the criteria.
To this, we add a method for each addSelectXXX, and
methods -- for each select -- to convert native types
to objects.
So, for equalTo, we have:
public void addSelectEqualTo(String attributeName,
Object value)
{
criteria.addElement(new
CriteriaEqualTo(attributeName, value));
}
public void addSelectEqualTo(String attributeName,
int value)
throws Exception
{
addSelectEqualTo(attributeName, new
Long((long)value));
}
public void addSelectEqualTo(String attributeName,
long value)
// ... blah, blah, same stuff for float and double.
I used Scott's name for CriteriaEqualTo, and I think
we should.
If you want, I can zip my code for this.
You should delete the OrCriteria class. Scott's paper
suggests to add an instance of PersistentCriteria.
So, in PersistentCriteria, we code:
public void addOrCriteria(PersistentCriteria
persistentCriteria)
{
criteria.addElement(persistentCriteria);
}
To see how this could be unwound, please see my
implementation of asSqlClause in the SqlStatement
class. This recursive definition is a very clever
idea by Scott. He describes the same technique to
nest transactions.
Another question I have is: Why put class map in the
PersistentObject (P.O.) class? I can't think of any
operation in P.O. that will use it. Anyway, you
should make class maps globally available by adding
something to PersistenceBroker, say:
ClassMap getClassMap(String name);
This is OK, because class maps, after being read by
the Broker, are static data.
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
