[Opensource] [FUTURE OF DB OBJECTS]

[Peter A. J. Pilgrim]

Michael Rimov wrote:
> Hey All,
> 
> -------------------------------------------------------------------------
> Future of DBObjects:
> 
> I've been already working on a DataObject API since Expresso 5, and the 
> roots of it are in place.  There's a goal that I have to have a series 
> of async DataObject APIs.  However, that is a long term goal for 
> Expresso 6, and I'm only "baby stepping" in that direction so we don't 
> lose anybody.  I'm at the point where we, as a community, need to make a 
> decision on how we want field access.  There are a few options:
> 
> Pseudocode:
> 
>     DBObject.getField().asString()/.asDate()/.asInteger()  etc.
> 
>         or
>     (Date)DBObject.getField()/(String)DBObject.getField() etc.
>         or
> 
>     DBObject.getFieldString()/.getFieldInt()/.getFieldDecimal()
> 
> Maybe it's preference, but I don't really like the 3rd method, even 
> though that's what we're doing right now.  The biggest problem is that 
> it is part of the reason we have this monster of a DBObject class right 
> now.  By delegating conversion code to the field object (as in #1) we 
> slim down DBObject.   #2 is easier to code in that you make DBObject a 
> dynabean and leave it up to the coder to know what is what.... but I 
> think it might lead to weird class cast exceptions.  So I'm currently 
> leaning towards #1 as my own personal preference.
> 
> Now keep in mind that the finalization of this API won't be probably for 
> a year, so as far as rewriting code goes, you won't have to do it 
> immediately.  What are your guy's thoughts on this?  Which API method 
> would you prefer to see?  If you want it as is

As I said before the DBObject should store native JDBC types rather
than String types, because it save time and efficiency.
Consider read a String date from a DBObject or a web form, we
have to convert to a java.util.Date then store it back as String
inside a DBObject.


	String 	-> java.sql.Timestamp -> java.util.Data --> String


This is nonsense

I would prefer

	public Object  getFieldObject( String name );
	public void    setFieldObject( String name, Object value );
		// accessor mutator for getting native objects as to
		// and from the JDBC layer

	public int getFieldType( String name );
		// get the JDBC type e.g. java.sql.Types.REAL

The above should be enough to gauge the type of JDBC column and
perform your own conversions.

Unfortunately we have to be backwards compatible so

	public String  getField( String name );
	public void    setField( String name, String value );

has to live on.


-- 
Peter Pilgrim
ServerSide Java Specialist

My on-line resume and for interview videos about myself, J2EE
Open Source, Struts and Expresso.
    ||
    \\===>  `` http://www.xenonsoft.demon.co.uk/no-it-striker.html ''