db-torque-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Greg Monroe" <Greg.Mon...@DukeCE.com>
Subject SetByName, SetByPeerName, SetByPostion support / Generic String to Column Object utility class.
Date Thu, 25 May 2006 15:26:59 GMT
Just a quick heads up/RFC about a couple of minor enhancements that 
I'll be submitting via JIRA once I get The Enhanced Database Mapping 
[Jira - Torque22] issues resolved (Working thru your list slowly 
Thomas.. 8-)  ).
 
The first one is to add functions to matching setBy* methods that match
the 
existing  getBy* methods in the Generated record classes.  These will
have
the signatures of:
 
    public boolean setByName( String fieldName, Object value ) 
                                        throws IllegalArgumentException 
    public boolean setByPeerName( String fieldName, Object value ) 
                                        throws IllegalArgumentException 
    public boolean setByPositon( int position, Object value ) 
                                        throws IllegalArgumentException 
 
The boolean will be false if the field can't be set (unknown name or
field is protected, i.e. readOnly ).  IllegalArgumentExceptions will be 
thrown if the Object does not match the fields required type.  The 
implimentations handle conversion to primative if needed.
 
The BaseObject methods will be "not implemented" exception stubs.
 
Currently, generation of these methods can be turned on and off by the 
existing torque.addGetByNameMethod option.  Just because it's easy
and doesn't impact the build properties. Should there be yet another 
option or should this option name change?
 
The reason for this is to make it possible to have methods who's
parameters
specify BaseObject fully interact with ANY record object.  Currently,
the 
only way to set values in a record using a BaseObject defined variable
is
to do a compile time cast and call the appropriate set<Field> method.
This
will allow values to be set, if you have a runtime determined field name
and
a BaseObject handle.
 
For example, suppose there is the need for a generic import function to 
support something like XML import 8-), or CSV or just transfering
records
from one database schema (Torque or Physical) to another with a matching
or improved/new revision schema.  With this, you can do things like:
 
void convert( List mixedListOfOldRecords, String newDBName ) {
...
    <iterate over mixedListOfRecords>
    ...
    BaseObject oldRecord = mixedListOfOldRecords.get(x);
    String tableName = oldRecord.getTableMap().getName();
    ...
    DatabaseMap dMap = Torque.getDatabaseMap(newDBName);
    dMap.initialize();
    TableMap tMap = dMap.getTable(tableName);
    BaseObject newRecord = tMap.getOMClass().newInstance();
    ColumnMaps[] columns = tMap.getColumns();
    <iterate over columns>
        ...
        String fieldName = column.getJavaName();
        Object value = oldRecord.getByName(fieldName);
        newRecord.setByName(fieldName, value);
    ... 
 
Note that mixedListOfOldRecords could be created with all required
foreign key records as well as sub-records.
 
The second minor enhancement is a utility class that will handle
converting 
data between String values and object values.  It will have some methods

like:
 
public Object getObjectValue( String peerName, String value )
   throws IllegalArgumentException.
public Object getStringValue( BaseObject record, String peerName )...
 
The getObjectValue will return an object that matches the specified
column's type.  This is useful just about anytime you are dealing 
with string input (like from XML imports or user forms).
 
The getStringValue is probably less useful but makes for symmetry.  The
one
big benefit I can see would be that we could centralize the problems
with 
converting from Date object to (and from) Strings.
 
Have I totally confused everyone now?
 
TIA
 
Greg
 
Greg Monroe <Monroe@DukeCE.com> (919)680-5050
C&IS Solutions Team Lead
Duke Corporate Education, Inc.
333 Liggett St.
Durham, NC 27701

 

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.



Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message