Re: SetByName, SetByPeerName, SetByPostion support / Generic String to Column Object utility class.

[Thomas Fischer <tf...@apache.org>]

Greg, I like the first improvement and think it will improve Torque.
I have read the second improvement thrice now but still do not 
understand what it does and what it is for. Can you please enlighten us 
earth-bound spirits by giving some example ?

    Thanks in advance,

       Thomas

On Thu, 25 May 2006, Greg Monroe wrote:

> 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 <Mo...@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.
>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: torque-dev-unsubscribe@db.apache.org
For additional commands, e-mail: torque-dev-help@db.apache.org