[Opensource] [FUTURE OF DB OBJECTS]

[D Lloyd]

I thought the issue was if DBObject had JDBC types that you access through
DBObject.getFieldDate()
       or
DBObject had DBField objects that had JDBC types that you access through
DBObject.getField(X).getDate() - this one has the advantage of storing
things other than JDBC data or returning data as a complex type - a blob
storing a serialized class could return the class instance hiding how the
class is stored.

Any clarification?

Either way we would need to keep DBObject.getField(String) at least for a
while.

David Lloyd

--- "Peter A. J. Pilgrim" <peterp at xenonsoft.demon.co.uk> wrote:
> 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


__________________________________________________
Do you Yahoo!?
HotJobs - Search new jobs daily now
http://hotjobs.yahoo.com/