PLEASE LET ME KNOW HOW I CAN REMOVE MISELF FROM EMAIL LIST. I DON'T WANT TO RECEIVE ALL THESE EMAILS BUT I DO NOT SEE ANY UNSUBSCRBE LINK.
ELI > Date: Thu, 26 Nov 2009 17:46:40 +0000 > From: j...@apache.org > To: dev@ofbiz.apache.org > Subject: [jira] Commented: (OFBIZ-3245) Sandbox: Integrating The New > Conversion Framework Into The Entity Engine > > > [ > https://issues.apache.org/jira/browse/OFBIZ-3245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12782951#action_12782951 > ] > > David E. Jones commented on OFBIZ-3245: > --------------------------------------- > > It sounds like you're still misunderstanding Adrian. Remember that you are > adding the idea of supporting multiple object types externally, and that > didn't exist before. The Entity Engine previously dealt with only one object > type for each field type, and that object type was the same for the external > API as it was for the JDBC driver. > > This was done by using the JDBC API to set a specific type of object when > writing, and also using the JDBC API to get a specific type of object when > reading. There is nothing that just does a get and lets the JDBC driver > choose what sort of object to return. > > So, in other words there was only a need for one object type. > > With what you have going now, I still think there is only a need for one java > object type. Having multiple attributes for this would be confusing, or at > least it is to me... > > I still don't see an answer to the question of what you would do with the > current java-type attribute if you introduced a new one, no matter what it > was named. So, what would it be used for? > > If it's not used for anything else in your scheme, then let's use it for what > it has always been used for and that is to specify the main java object type > that will be used to represent a field, and in the case of supporting > conversions it would be the one that we trying to convert to before setting > in the JDBC API, and for getting the one we would use to get a specific > object type from the JDBC API before possibly converting it to the object > type requested by the calling code (if you plan to support that, possibly > using existing GenericEntity.get* methods). > > In short, if we're changing the semantics, why does it matter what sort of > interpretation you had before for the java-type attribute? Why not just use > it instead of introducing something else that makes it tough to figure out > what these things mean... since it sounds like there wouldn't be any sort of > meaning for the java-type attribute any more. > > > 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, > > 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. > _________________________________________________________________ Bing brings you maps, menus, and reviews organized in one place. http://www.bing.com/search?q=restaurants&form=MFESRP&publ=WLHMTAG&crea=TEXT_MFESRP_Local_MapsMenu_Resturants_1x1
