[jira] Issue Comment Edited: (OFBIZ-3245) Sandbox: Integrating The New Conversion Framework Into The Entity Engine

["Adrian Crum (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/OFBIZ-3245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12782481#action_12782481 ] 

Adrian Crum edited comment on OFBIZ-3245 at 11/25/09 4:25 PM:
--------------------------------------------------------------

I'm sure I am the one who is confused. It appeared to me the java-type attribute was being used as a target object type for the framework. If it was originally intended to be the object type the JDBC driver is expecting, then that's not how it is being used today. Or the fieldtype*.xml files are very much out-of-date.

It appeared to me that the java-type attribute was a way of abstracting the database details, in effect saying "regardless of how this value in stored in the database, it will be xxx type when used in the framework." Based on your comment, I now know this is wrong, but like I said - that is how it is being used in the current code.

My inaccurate evaluation of the  java-type's use actually makes more sense than the original intent. For example, what Java object type should you expect to get when you call GenericValue.get()? I always assumed it was the type specified in the java-type attribute. Using that attribute the way it was originally intended, I won't know what Java object type I will get - because each JDBC driver might return something different.

So, based on my misunderstanding of what that attribute was used for, this is how I pictured the changes proposed here working:

Database -> JDBC driver -> sql-object-type -> (converted to) java-type -> framework code

Last night I came up with a better name for the new attribute to help make things clearer:

Database -> JDBC driver -> jdbc-type -> (converted to) java-type -> framework code

In the majority of field types there is no conversion necessary. For example, all JDBC drivers are going to use the java.lang.String java object type for CHAR and VARCHAR, java.sql.Timestamp for TIMESTAMP, etc. But there are differences in how drivers handle some of the other SQL data types. It would be nice if client code didn't need to know about those differences.



      was (Author: adrianc@hlmksw.com):
    I'm sure I am the one who is confused. It appeared to me the java-type attribute was being used as a target object type for the framework. If it was originally intended to be the object type the JDBC driver is expecting, then that's not how it is being used today. Or the fieldtype*.xml files are very much out-of-date.

It appeared to me that the java-type attribute was a way of abstracting the database details, in effect saying "regardless of how this value in stored in the database, it will be xxx type when used in the framework." Based on your comment, I now know this is wrong, but like I said - that is how it is being used in the current code.

My inaccurate evaluation of the  java-type's use actually makes more sense than the original intent. For example, what Java object type should you expect to get when you call GenericValue.get()? I always assumed it was the type specified in the java-type attribute. Using that attribute the way it was originally intended, I won't know what Java object type I will get - because each JDBC driver might return something different.

So, based on my misunderstanding of what that attribute was used for, this is how I pictured the changes proposed here working:

Database -> JDBC driver -> sql-object-type (converted to) -> java-type -> framework code

Last night I came up with a better name for the new attribute to help make things clearer:

Database -> JDBC driver -> jdbc-type (converted to) -> java-type -> framework code

In the majority of field types there is no conversion necessary. For example, all JDBC drivers are going to use the java.lang.String java object type for CHAR and VARCHAR, java.sql.Timestamp for TIMESTAMP, etc. But there are differences in how drivers handle some of the other SQL data types. It would be nice if client code didn't need to know about those differences.


  
> Sandbox: Integrating The New Conversion Framework Into The Entity Engine
> ------------------------------------------------------------------------
>
>                 Key: OFBIZ-3245
>                 URL: https://issues.apache.org/jira/browse/OFBIZ-3245
>             Project: OFBiz
>          Issue Type: Improvement
>          Components: framework
>    Affects Versions: SVN trunk
>            Reporter: Adrian Crum
>            Assignee: Adrian Crum
>            Priority: Minor
>         Attachments: conversion.patch, conversion.patch, conversion.patch
>
>
> This issue contains a patch intended for evaluation before it is committed. See comments for details.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.