Base Object / Record Object Design ( Was: Torque 4.0 plan )

Comments inline...

> -----Original Message-----
> Thomas Fischer said:
> 
> On Thu, 30 Nov 2006, Greg Monroe wrote:
> > ...
> 
> > To support this and also assist in the Village exorcism,
> > I'd propose making the BaseObject an actual storage
> > implimentation, like Village Record or ResultsSet.  Internally
> > the data would be stored as objects in OrderedMap with the
> > getBy/setBy methods being the BaseObject access points.
> >
> > This would allow executeQuery to return a list of BaseObject
> > records.
> >
> > Additionally, the generated record objects could make use
> > of this new base class to support things like isNull() on
> > primitives.  We could also use this to track modified and
> > unmodified column values, which would be very useful (e.g.
> > updating tables without primary keys).
> 
> I'm note sure whether this is the best possible approach. I'd 
> rather work with a jdbc result set and generate a method that 
> directly populates an object from the jdbc result set. This 
> has the advantage that you can rely on type conversion of the 
> jdbcDriver (getAsInt etc) and do not have the trouble to store 
> which type which object is. It is also faster and less 
> memory-consuming.

I can see that.  But if we hope to support non-record queries,
we'll still need to have a Generic Record object.  In my mind,
I was combining the solution to the two.

FWIW, I was thinking that the generated record object would be 
the one to track the object type.  E.g., rather than generate 
field definition in the Base object, the getColumn() methods
would be generated to get the correct object from the list
(by name or position) and return it cast as the correct object.

One advantage I can see with a more solid BaseObject is that
it could make doing global changes across all generated code
easier.  E.g., create a subclass and generate with your 
local BaseObjects to extend this rather than the Torque
default.
> 
> This can be achieved in two different ways. Thomas V's 
> favorite is just calling an abstract method in BasePeer 
> which gets overridden in each concrete peer and which is 
> called for each row in the resultSet. something like
> 
> ResultSet resultSet = doSelectSomething();
> while(resultSet.next())
> {
>    resultList.add(createObject(resultSet))
> }
> 
> and the createObject() method would be generated for each 
> peer.
> 
> My favourite is to use an ObjectCreator class, which would be 
> called for each row in a resultSet and create an object out 
> of it. The concrete Peer itself could be the Object creator.
> 
> The first has the advantage of being the simplest possible 
> approach, the second is more flexible (the method which does 
> the selects and calls the ObjectCreator could be used for 
> custom object creators, which use the values in the data row 
> in any way they like)., and so provide a replacement for the
> doSelectVollageRecords, which is uften used for custom selects 
> now.
> 
Hmm, not sure which is better.  One idea to throw into the mix
is to do the following:

Make generation of the getBy/setBy methods non-optional. The 
set methods currently do Object type checking and can easily
be modified to save them into the Object based field storage
(where ever that ends up) Then all you need to populate an 
object is to do something like:

----------------------
void populate(BaseObject rec, ResultSet rs ) 
{

  ColumnMap columns[] = rec.getTableMap().getColumns();

// Note: could simplify this by generating a column name 
// array in peer or maybe using a metadata call to get the
// column names.

  for ( int i = 0; I < columns.length; i++ ) 
  {
    String columnName = columns[i].getName();
    Object value = null;
    try 
    {
      value = resultSet.getObject(columns[i].getName());
    } 
    catch ( SQLException e ) 
    {
        throw TorqueException(
           "Result set did not include a value for col X",e);
    }
// Possibly need some value "massaging method" here to handle JDBC 
// variances, e.g. Oracle driver and Timestamps?

    rec.setByName(columns[i].getJavaName(), value);
  } 
}
------------------------

I think we need to make sure that whatever solution we 
use can be locally modified to support JDBC variances.  
Maybe having a "mapping" JDBC to Torque types mapping 
object in the DB adaptor would be a good place.  
Hopefully, it will just be a common do nothing method.

We also need to consider cases where an DB schema column
type does not map directly into Torque. There are cases
in the Generator like SQL type DECIMAL(19,0) being mapped 
into Torque BIGINT. There are also cases where people have 
mapped existing application DB schema's into Torque and
have "gotten away" with close maps (E.g., the problem with
NUMERIC being mapped into DOUBLE).

If you consider these, I'm not sure we can totally depend 
on JDBC to do the right thing.  We probably will have to 
design in some type of conversion mechanism.

Greg

Duke CE Privacy Statement
Please be advised that this e-mail and any files transmitted with it are 
confidential communication or may otherwise be privileged or confidential and 
are intended solely for the individual or entity to whom they are addressed.  
If you are not the intended recipient you may not rely on the contents of this 
email or any attachments, and we ask that you  please not read, copy or 
retransmit this communication, but reply to the sender and destroy the email, 
its contents, and all copies thereof immediately.  Any unauthorized 
dissemination, distribution or copying of this communication is strictly 
prohibited.