OFBiz › OFBiz - Dev

Field max size based on DB field info

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

10 messages Options

BJ Freeman

Field max size based on DB field info

Up till now I assumed the DB field info was fed back into the entities
when field size as defined.
questions:
Does doing this break any models or design goals?
Is there a reason this DB field info is not used in the ModelFormField.java

Jacques Le Roux

Re: Field max size based on DB field info

Administrator

It seems that nothing happenned (no answers, etc.) after this message, please why ?

Thanks

Jacques

From: "BJ Freeman" <[hidden email]>
> Up till now I assumed the DB field info was fed back into the entities
> when field size as defined.
> questions:
> Does doing this break any models or design goals?
> Is there a reason this DB field info is not used in the ModelFormField.java
>

BJ Freeman

Re: Field max size based on DB field info

In reply to this post by BJ Freeman

see https://issues.apache.org/jira/browse/OFBIZ-2021
also

Jacques Le Roux sent the following on 5/9/2009 2:56 PM:

> It seems that nothing happenned (no answers, etc.) after this message,
> please why ?
>
> Thanks
>
> Jacques
>
> From: "BJ Freeman" <[hidden email]>
>> Up till now I assumed the DB field info was fed back into the entities
>> when field size as defined.
>> questions:
>> Does doing this break any models or design goals?
>> Is there a reason this DB field info is not used in the
>> ModelFormField.java
>>
>
>

--
BJ Freeman
http://www.businessesnetwork.com/automation
http://bjfreeman.elance.com
http://www.linkedin.com/profile?viewProfile=&key=1237480&locale=en_US&trk=tab_pro
Systems Integrator.

Harmeet Bedi

Re: Field max size based on DB field info

In reply to this post by BJ Freeman

We did some work in this area:

The issues were the following
1. If you pass a string that is larger than type of db field, transaction crashes
2. UI forms are not necessary same as db entities. UI forms are persisted through services db entities or services. It is hard to tie UI forms with actual persistence to ensure safety of (1). Best approach may be to have conservative defaults.
3. For text fields and text areas UI should display the max size and prevent additional entry.
4. Concrete DB Info is based on db type as per fieldtype(dbtype).xml

There were a couple of realizations.. Ofbiz data dictionary is nicely done. A field usually means the same thing and has same dimension if present in multiple tables. e.g. partyId is same (maxsize 20) and so is comments(maxsize 255). There are very few anomalies. These were

# field to list of 'entity.size', if size varies per entity
entitysize.accountNumber=EftAccount:255,PartyCarrierAccount:20,PartyGroup:100,PayrollPreference:60
entitysize.cardNumber=CreditCard:255,GiftCard:255,GiftCardFulfillment:255,ValueLinkFulfillment:60
entitysize.city=PostalAddress:100,ZipSalesRuleLookup:60,ZipSalesTaxLookup:60
entitysize.contentId=CommEventContentAssoc:20,Content:20,ContentApproval:20,ContentAssoc:20,ContentAttribute:20,ContentMetaData:20,ContentPurpose:20,ContentRevision:20,ContentRevisionItem:20,ContentRole:20,CustRequestContent:20,OrderContent:20,PartyContent:20,PartyResume:20,ProdConfItemContent:20,ProductCategoryContent:20,ProductContent:20,ServerHit:255,ServerHitBin:255,SubscriptionResource:20,SurveyResponseAnswer:20,WebPage:20,WebSiteContent:20,WebSitePathAlias:20,WebSitePublishPoint:20,WorkEffortContent:20
entitysize.countryCode=CountryCapital:20,CountryCode:20,CountryTeleCode:20,TelecomNumber:10
entitysize.description=AccommodationClass:255,AccommodationMapType:255,AccommodationSpot:255,AcctgTrans:255,AcctgTransEntry:255,AcctgTransEntryType:255,AcctgTransType:255,Agreement:255,AgreementItemType:255,AgreementTerm:255,AgreementType:255,BenefitType:255,BillingAccount:255,BudgetItemType:255,BudgetReviewResultType:255,BudgetScenario:255,BudgetType:255,CharacterSet:255,CommContentAssocType:255,CommunicationEventPrpTyp:255,CommunicationEventPurpose:255,CommunicationEventType:255,CommunicationEventWorkEff:255,ConfigOptionProductOption:255,ContactList:255,ContactListType:255,ContactMechPurposeType:255,ContactMechType:255,Container:255,ContainerType:255,Content:255,ContentAssocPredicate:255,ContentAssocType:255,ContentOperation:255,ContentPurposeType:255,ContentType:255,CostComponentCalc:255,CostComponentType:255,CurrencyDimension:255,CustRequest:255,CustRequestCategory:255,CustRequestItem:255,CustRequestResolution:255,CustRequestType:255,CustomMethod:255,CustomMethodType:255,DataResourceType:255,DataSource:255,DataSourceType:255,DataTemplateType:255,DateDimension:255,DeductionType:255,Deliverable:255,DeliverableType:255,DepreciationMethod:255,DocumentType:255,EmplLeave:255,EmplLeaveType:255,EmplPositionClassType:255,EmplPositionType:255,EmploymentAppSourceType:255,Enumeration:255,EnumerationType:255,Example:255,ExampleFeature:255,ExampleFeatureApplType:255,ExampleItem:255,ExampleType:255,Facility:255,FacilityGroup:255,FacilityGroupType:255,FacilityType:255,FinAccountTransType:255,FinAccountType:255,FixedAssetIdentType:255,FixedAssetProductType:255,FixedAssetStdCostType:255,FixedAssetType:255,GeoAssocType:255,GeoType:255,GlAccount:255,GlAccountClass:255,GlAccountGroup:255,GlAccountGroupType:255,GlAccountType:255,GlFiscalType:255,GlReconciliation:255,GlResourceType:255,GlXbrlClass:255,GoodIdentificationType:255,InventoryItemDetail:255,InventoryItemLabel:255,InventoryItemLabelType:255,InventoryItemType:255,Invoice:255,InvoiceItem:255,InvoiceItemType:255,InvoiceTerm:255,InvoiceType:255,MetaDataPredicate:255,MimeType:255,MrpEventType:255,NeedType:255,OagisMessageErrorInfo:2147483647,OrderAdjustment:255,OrderAdjustmentType:255,OrderBlacklistType:255,OrderContentType:255,OrderItemAssocType:255,OrderItemPriceInfo:255,OrderItemType:255,OrderTerm:255,OrderType:255,Party:2147483647,PartyClassification:255,PartyClassificationGroup:255,PartyClassificationType:255,PartyContentType:255,PartyNeed:255,PartyQualType:255,PartyRelationshipType:255,PartyTimeTracker:60,PartyType:255,PaymentMethod:255,PaymentMethodType:255,PaymentType:255,PerfRatingType:255,PerfReviewItemType:255,PeriodType:255,Picklist:255,PortalPage:255,PortalPortlet:255,PriorityType:255,ProdCatalogCategoryType:255,ProdConfItemContentType:255,Product:255,ProductAssocType:255,ProductCategory:255,ProductCategoryContentType:255,ProductCategoryType:255,ProductConfig:255,ProductConfigConfig:255,ProductConfigItem:255,ProductConfigOption:255,ProductConfigOptionIactn:255,ProductContentType:255,ProductEnumerationType:255,ProductFeature:255,ProductFeatureApplType:255,ProductFeatureCategory:255,ProductFeatureGroup:255,ProductFeatureIactnType:255,ProductFeatureType:255,ProductGeo:255,ProductMaintType:255,ProductManufacturingRule:255,ProductMeterType:255,ProductPriceActionType:255,ProductPricePurpose:255,ProductPriceRule:255,ProductPriceType:255,ProductStoreGroup:255,ProductStoreGroupType:255,ProductTag:100,ProductTagFieldAttribute:100,ProductTagStyle:100,ProductType:255,QuantityBreakType:255,Quote:255,QuoteAdjustment:255,QuoteType:255,RateType:255,RejectionReason:255,Requirement:255,RequirementType:255,ResponsibilityType:255,ReturnAdjustment:255,ReturnAdjustmentType:255,ReturnHeaderType:255,ReturnItem:255,ReturnItemType:255,ReturnReason:255,ReturnType:255,RoleType:255,SaleType:255,SalesOpportunity:2147483647,SalesOpportunityHistory:2147483647,SalesOpportunityStage:255,SecurityGroup:255,SecurityPermission:255,SegmentGroup:255,SegmentGroupType:255,ServerHitType:255,ShipmentBoxType:255,ShipmentContactMechType:255,ShipmentMethodType:255,ShipmentType:255,ShippingDocument:255,ShoppingList:255,ShoppingListType:255,SkillType:255,StatusItem:255,StatusType:255,Subscription:255,SubscriptionResource:255,SubscriptionType:255,SupplierPrefOrder:255,SupplierProductFeature:100,SupplierRatingType:255,Survey:255,SurveyApplType:255,SurveyQuestion:255,SurveyQuestionCategory:255,SurveyQuestionOption:255,SurveyQuestionType:255,Tag:100,TagFieldAttribute:100,TagStyle:100,TaxAuthorityAssocType:255,TaxAuthorityRateProduct:255,TaxAuthorityRateType:255,TechDataCalendar:255,TechDataCalendarExcDay:255,TechDataCalendarExcWeek:255,TechDataCalendarWeek:255,TermType:255,TerminationReason:255,TerminationType:255,Testing:255,TestingNode:255,TestingType:255,TrackingCode:255,TrackingCodeType:255,TrainingClassType:255,UnemploymentClaim:255,Uom:255,UomType:255,UserAgentMethodType:255,UserAgentType:255,UserPrefGroupType:255,VarianceReason:255,VisualTheme:255,WebPreferenceType:255,WebSiteContentType:255,WorkEffort:255,WorkEffortAssocType:255,WorkEffortContentType:255,WorkEffortGoodStandardType:255,WorkEffortPurposeType:255,WorkEffortType:255,WorkReqFulfType:255
entitysize.extension=DataTemplateType:60,FacilityContactMech:10,PartyContactMech:255
entitysize.idCode=ProductFeature:20,SupplierProductFeature:20,ZipSalesRuleLookup:60
entitysize.idValue=FixedAssetIdent:255,GoodIdentification:60
entitysize.mapKey=AddressMatchMap:255,ContentAssoc:100,WebSitePathAlias:100
entitysize.pinNumber=GiftCard:255,GiftCardFulfillment:255,ValueLinkFulfillment:60
entitysize.referenceId=OagisMessageErrorInfo:60,OagisMessageInfo:60,SurveyResponse:255
entitysize.serviceName=Content:255,JobSandbox:100,ProductStoreShipmentMeth:255,ServiceSemaphore:100
entitysize.sessionId=CatalinaSession:60,Visit:255
entitysize.taxable=Product:1,ZipSalesRuleLookup:60
entitysize.title=PartyQual:60,ProductStore:100,ProductTag:100,ProductTagFieldAttribute:100,ProductTagStyle:100
entitysize.transactionId=OrderHeader:60,PosTerminalLog:20

Here is what we did.

- Crawled our target database postgres to build columnid to maxsize mapping for all entities and put it into a properties file. From our ofbiz fork late last year there were 1400 column names with with unambiguous maxsize and about 17 ambiguous columns size (as mentioned above). For ambiguous column names we assumed the max size was lower of the possible values. e.g. accountNumber has maxsize 60(from PayrollPreference not EftAccount)

- Our UI forms could use default column names and not care about db entities, services perisistence etc.
So there if UI had these 3 columns.
<field name="partyId"><text ...></field>
<field name="comments"><textarea ...></field>
<field name="accountNumber"><text ...></field>
The model forms take into account that partyId means maxsize 20, comments 255 and accountNumber 60 and the generation is changed accordingly. Properties are cached through UtilProperties(UtilCache) so efficient.

The nice thing is that by basing max size on column id, not entity and column id, maxsize value add is more or less transparent.

We only auto apply maxsize if form does not explicitly specify. in a small number of cases it is better to override defaults by explicitly specifying. e.g. crawler gave
carrierRestrictionDesc=2147483647
this is for
<field name="carrierRestrictionDesc" type="very-long"></field>
This is text type. One could do something more reasonable for Text types.. they a small number in any case.

Attached is the file we used to generate. Feel free to use it as you see fit. it generates FieldSize.properties (if there max size per column name is not ambiguous) and FieldSizeAnomaly.properties for columns where data dictionary has anomalous meaning.. (likely bugs)

Harmeet

----- Original Message -----
From: "Jacques Le Roux" <[hidden email]>
To: [hidden email]
Sent: Saturday, May 9, 2009 5:56:33 PM GMT -05:00 US/Canada Eastern
Subject: Re: Field max size based on DB field info

It seems that nothing happenned (no answers, etc.) after this message, please why ?

Thanks

Jacques

From: "BJ Freeman" <[hidden email]>
> Up till now I assumed the DB field info was fed back into the entities
> when field size as defined.
> questions:
> Does doing this break any models or design goals?
> Is there a reason this DB field info is not used in the ModelFormField.java
>

GenDataDictionary.java (6K) Download Attachment

BJ Freeman

Re: Field max size based on DB field info

In reply to this post by BJ Freeman

as per the jira this is all controlled by
modelformfield.java, not the entity field type.
the Jira was to address changing this.
the original question was

Does doing this break any models or design goals?
Is there a reason this DB field info is not used in the ModelFormField.java

Harmeet Bedi sent the following on 5/10/2009 7:40 AM:

> We did some work in this area:
>
> The issues were the following
> 1. If you pass a string that is larger than type of db field, transaction crashes
> 2. UI forms are not necessary same as db entities. UI forms are persisted through services db entities or services. It is hard to tie UI forms with actual persistence to ensure safety of (1). Best approach may be to have conservative defaults.
> 3. For text fields and text areas UI should display the max size and prevent additional entry.
> 4. Concrete DB Info is based on db type as per fieldtype(dbtype).xml
>
> There were a couple of realizations.. Ofbiz data dictionary is nicely done. A field usually means the same thing and has same dimension if present in multiple tables. e.g. partyId is same (maxsize 20) and so is comments(maxsize 255). There are very few anomalies. These were
>
> # field to list of 'entity.size', if size varies per entity
> entitysize.accountNumber=EftAccount:255,PartyCarrierAccount:20,PartyGroup:100,PayrollPreference:60
> entitysize.cardNumber=CreditCard:255,GiftCard:255,GiftCardFulfillment:255,ValueLinkFulfillment:60
> entitysize.city=PostalAddress:100,ZipSalesRuleLookup:60,ZipSalesTaxLookup:60
> entitysize.contentId=CommEventContentAssoc:20,Content:20,ContentApproval:20,ContentAssoc:20,ContentAttribute:20,ContentMetaData:20,ContentPurpose:20,ContentRevision:20,ContentRevisionItem:20,ContentRole:20,CustRequestContent:20,OrderContent:20,PartyContent:20,PartyResume:20,ProdConfItemContent:20,ProductCategoryContent:20,ProductContent:20,ServerHit:255,ServerHitBin:255,SubscriptionResource:20,SurveyResponseAnswer:20,WebPage:20,WebSiteContent:20,WebSitePathAlias:20,WebSitePublishPoint:20,WorkEffortContent:20
> entitysize.countryCode=CountryCapital:20,CountryCode:20,CountryTeleCode:20,TelecomNumber:10
> entitysize.description=AccommodationClass:255,AccommodationMapType:255,AccommodationSpot:255,AcctgTrans:255,AcctgTransEntry:255,AcctgTransEntryType:255,AcctgTransType:255,Agreement:255,AgreementItemType:255,AgreementTerm:255,AgreementType:255,BenefitType:255,BillingAccount:255,BudgetItemType:255,BudgetReviewResultType:255,BudgetScenario:255,BudgetType:255,CharacterSet:255,CommContentAssocType:255,CommunicationEventPrpTyp:255,CommunicationEventPurpose:255,CommunicationEventType:255,CommunicationEventWorkEff:255,ConfigOptionProductOption:255,ContactList:255,ContactListType:255,ContactMechPurposeType:255,ContactMechType:255,Container:255,ContainerType:255,Content:255,ContentAssocPredicate:255,ContentAssocType:255,ContentOperation:255,ContentPurposeType:255,ContentType:255,CostComponentCalc:255,CostComponentType:255,CurrencyDimension:255,CustRequest:255,CustRequestCategory:255,CustRequestItem:255,CustRequestResolution:255,CustRequestType:255,CustomMethod:255,CustomMethodType:2

55,DataResourceType:255,DataSource:255,DataSourceType:255,DataTemplateType:255,DateDimension:255,DeductionType:255,Deliverable:255,DeliverableType:255,DepreciationMethod:255,DocumentType:255,EmplLeave:255,EmplLeaveType:255,EmplPositionClassType:255,EmplPositionType:255,EmploymentAppSourceType:255,Enumeration:255,EnumerationType:255,Example:255,ExampleFeature:255,ExampleFeatureApplType:255,ExampleItem:255,ExampleType:255,Facility:255,FacilityGroup:255,FacilityGroupType:255,FacilityType:255,FinAccountTransType:255,FinAccountType:255,FixedAssetIdentType:255,FixedAssetProductType:255,FixedAssetStdCostType:255,FixedAssetType:255,GeoAssocType:255,GeoType:255,GlAccount:255,GlAccountClass:255,GlAccountGroup:255,GlAccountGroupType:255,GlAccountType:255,GlFiscalType:255,GlReconciliation:255,GlResourceType:255,GlXbrlClass:255,GoodIdentificationType:255,InventoryItemDetail:255,InventoryItemLabel:255,InventoryItemLabelType:255,InventoryItemType:255,Invoice:255,InvoiceItem:255,InvoiceItemT
ype:255,InvoiceTerm:255,InvoiceType:255,MetaDataPredicate:255,MimeType:255,MrpEventType:255,NeedType:255,OagisMessageErrorInfo:2147483647,OrderAdjustment:255,OrderAdjustmentType:255,OrderBlacklistType:255,OrderContentType:255,OrderItemAssocType:255,OrderItemPriceInfo:255,OrderItemType:255,OrderTerm:255,OrderType:255,Party:2147483647,PartyClassification:255,PartyClassificationGroup:255,PartyClassificationType:255,PartyContentType:255,PartyNeed:255,PartyQualType:255,PartyRelationshipType:255,PartyTimeTracker:60,PartyType:255,PaymentMethod:255,PaymentMethodType:255,PaymentType:255,PerfRatingType:255,PerfReviewItemType:255,PeriodType:255,Picklist:255,PortalPage:255,PortalPortlet:255,PriorityType:255,ProdCatalogCategoryType:255,ProdConfItemContentType:255,Product:255,ProductAssocType:255,ProductCategory:255,ProductCategoryContentType:255,ProductCategoryType:255,ProductConfig:255,ProductConfigConfig:255,ProductConfigItem:255,ProductConfigOption:255,ProductConfigOptionIactn:255,Prod
uctContentType:255,ProductEnumerationType:255,ProductFeature:255,ProductFeatureApplType:255,ProductFeatureCategory:255,ProductFeatureGroup:255,ProductFeatureIactnType:255,ProductFeatureType:255,ProductGeo:255,ProductMaintType:255,ProductManufacturingRule:255,ProductMeterType:255,ProductPriceActionType:255,ProductPricePurpose:255,ProductPriceRule:255,ProductPriceType:255,ProductStoreGroup:255,ProductStoreGroupType:255,ProductTag:100,ProductTagFieldAttribute:100,ProductTagStyle:100,ProductType:255,QuantityBreakType:255,Quote:255,QuoteAdjustment:255,QuoteType:255,RateType:255,RejectionReason:255,Requirement:255,RequirementType:255,ResponsibilityType:255,ReturnAdjustment:255,ReturnAdjustmentType:255,ReturnHeaderType:255,ReturnItem:255,ReturnItemType:255,ReturnReason:255,ReturnType:255,RoleType:255,SaleType:255,SalesOpportunity:2147483647,SalesOpportunityHistory:2147483647,SalesOpportunityStage:255,SecurityGroup:255,SecurityPermission:255,SegmentGroup:255,SegmentGroupType:255,Serv
erHitType:255,ShipmentBoxType:255,ShipmentContactMechType:255,ShipmentMethodType:255,ShipmentType:255,ShippingDocument:255,ShoppingList:255,ShoppingListType:255,SkillType:255,StatusItem:255,StatusType:255,Subscription:255,SubscriptionResource:255,SubscriptionType:255,SupplierPrefOrder:255,SupplierProductFeature:100,SupplierRatingType:255,Survey:255,SurveyApplType:255,SurveyQuestion:255,SurveyQuestionCategory:255,SurveyQuestionOption:255,SurveyQuestionType:255,Tag:100,TagFieldAttribute:100,TagStyle:100,TaxAuthorityAssocType:255,TaxAuthorityRateProduct:255,TaxAuthorityRateType:255,TechDataCalendar:255,TechDataCalendarExcDay:255,TechDataCalendarExcWeek:255,TechDataCalendarWeek:255,TermType:255,TerminationReason:255,TerminationType:255,Testing:255,TestingNode:255,TestingType:255,TrackingCode:255,TrackingCodeType:255,TrainingClassType:255,UnemploymentClaim:255,Uom:255,UomType:255,UserAgentMethodType:255,UserAgentType:255,UserPrefGroupType:255,VarianceReason:255,VisualTheme:255,Web
PreferenceType:255,WebSiteContentType:255,WorkEffort:255,WorkEffortAssocType:255,WorkEffortContentType:255,WorkEffortGoodStandardType:255,WorkEffortPurposeType:255,WorkEffortType:255,WorkReqFulfType:255

> entitysize.extension=DataTemplateType:60,FacilityContactMech:10,PartyContactMech:255
> entitysize.idCode=ProductFeature:20,SupplierProductFeature:20,ZipSalesRuleLookup:60
> entitysize.idValue=FixedAssetIdent:255,GoodIdentification:60
> entitysize.mapKey=AddressMatchMap:255,ContentAssoc:100,WebSitePathAlias:100
> entitysize.pinNumber=GiftCard:255,GiftCardFulfillment:255,ValueLinkFulfillment:60
> entitysize.referenceId=OagisMessageErrorInfo:60,OagisMessageInfo:60,SurveyResponse:255
> entitysize.serviceName=Content:255,JobSandbox:100,ProductStoreShipmentMeth:255,ServiceSemaphore:100
> entitysize.sessionId=CatalinaSession:60,Visit:255
> entitysize.taxable=Product:1,ZipSalesRuleLookup:60
> entitysize.title=PartyQual:60,ProductStore:100,ProductTag:100,ProductTagFieldAttribute:100,ProductTagStyle:100
> entitysize.transactionId=OrderHeader:60,PosTerminalLog:20
>
>
>
> Here is what we did.
>
> - Crawled our target database postgres to build columnid to maxsize mapping for all entities and put it into a properties file. From our ofbiz fork late last year there were 1400 column names with with unambiguous maxsize and about 17 ambiguous columns size (as mentioned above). For ambiguous column names we assumed the max size was lower of the possible values. e.g. accountNumber has maxsize 60(from PayrollPreference not EftAccount)
>
> - Our UI forms could use default column names and not care about db entities, services perisistence etc.
> So there if UI had these 3 columns.
> <field name="partyId"><text ...></field>
> <field name="comments"><textarea ...></field>
> <field name="accountNumber"><text ...></field>
> The model forms take into account that partyId means maxsize 20, comments 255 and accountNumber 60 and the generation is changed accordingly. Properties are cached through UtilProperties(UtilCache) so efficient.
>
> The nice thing is that by basing max size on column id, not entity and column id, maxsize value add is more or less transparent.
>
> We only auto apply maxsize if form does not explicitly specify. in a small number of cases it is better to override defaults by explicitly specifying. e.g. crawler gave
> carrierRestrictionDesc=2147483647
> this is for
> <field name="carrierRestrictionDesc" type="very-long"></field>
> This is text type. One could do something more reasonable for Text types.. they a small number in any case.
>
>
> Attached is the file we used to generate. Feel free to use it as you see fit. it generates FieldSize.properties (if there max size per column name is not ambiguous) and FieldSizeAnomaly.properties for columns where data dictionary has anomalous meaning.. (likely bugs)
>
> Harmeet
>
>
> ----- Original Message -----
> From: "Jacques Le Roux" <[hidden email]>
> To: [hidden email]
> Sent: Saturday, May 9, 2009 5:56:33 PM GMT -05:00 US/Canada Eastern
> Subject: Re: Field max size based on DB field info
>
> It seems that nothing happenned (no answers, etc.) after this message, please why ?
>
> Thanks
>
> Jacques
>
> From: "BJ Freeman" <[hidden email]>
>> Up till now I assumed the DB field info was fed back into the entities
>> when field size as defined.
>> questions:
>> Does doing this break any models or design goals?
>> Is there a reason this DB field info is not used in the ModelFormField.java
>>
>

--
BJ Freeman
http://www.businessesnetwork.com/automation
http://bjfreeman.elance.com
http://www.linkedin.com/profile?viewProfile=&key=1237480&locale=en_US&trk=tab_pro
Systems Integrator.

Harmeet Bedi

Re: Field max size based on DB field info

In reply to this post by BJ Freeman

I feel tying ui forms to persistent entities has some issues
- Front end may call more than one entity.
- It is hard to trace front end to all possible services and entity it may reference.
- It is not necessary that a UI form may be tied to an entity.

However tying front end to have reasonable defaults is a good thing from UI as
- safer: If you pass a string that is larger than type of db field, transaction crashes
- usability: For text fields and text areas UI should display the max size and prevent additional entry.

Proposal is this:
- Follow the good data dictionary principle where a field name means has a specific meaning and definition that is unambiguous across entities. mostly present in ofbiz
- Reuse the field names and definition to automatically deduce in user interface the intent of the front end wrt. max sizes and ideally data type.

Harmeet

----- Original Message -----
From: "BJ Freeman" <[hidden email]>
To: [hidden email]
Sent: Sunday, May 10, 2009 11:05:28 AM GMT -05:00 US/Canada Eastern
Subject: Re: Field max size based on DB field info

as per the jira this is all controlled by
modelformfield.java, not the entity field type.
the Jira was to address changing this.
the original question was

Does doing this break any models or design goals?
Is there a reason this DB field info is not used in the ModelFormField.java

Harmeet Bedi sent the following on 5/10/2009 7:40 AM:

--
BJ Freeman
http://www.businessesnetwork.com/automation
http://bjfreeman.elance.com
http://www.linkedin.com/profile?viewProfile=&key=1237480&locale=en_US&trk=tab_pro
Systems Integrator.

BJ Freeman

Re: Field max size based on DB field info

In reply to this post by BJ Freeman

I understand you point of view about not tying a UI field to a form
however the basic part of ofbiz design is that you don't have to
maintain the UI when you add to the entity.
The whole ofbiz design if focused that if you maintain the entity the
storage and UI are automatically updated.
In other words it make maintaining of the system easier.

to address the make field length over run if you design a hard coded UI
with say 60 as the length because the is the DB you are using, it is not
portable to say a DB that max length is 30.
The field length should not be made at the UI design level.
Under the proposal I thinking about, the UI field lengths should be
based on CSS and % not fixed.
As an example with tables, they adjust as the web browser is resized.
so must the Fields adjust as the browser it resized and or the fields
postion is adjusted to keep in in the viewer vision.

So some where in the rendering process of all handlers, should be the
method of adjusting entity fields to UI fields so the UI fields are
presentable, but limit the UI feilds so they are no longer than the
entity field types for that db.

I believe you and my goal are the same, have a presentable UI.
it is the method of how to do it that we differ.

Harmeet Bedi sent the following on 5/10/2009 8:23 AM:

> I feel tying ui forms to persistent entities has some issues
> - Front end may call more than one entity.
> - It is hard to trace front end to all possible services and entity it may reference.
> - It is not necessary that a UI form may be tied to an entity.
>
> However tying front end to have reasonable defaults is a good thing from UI as
> - safer: If you pass a string that is larger than type of db field, transaction crashes
> - usability: For text fields and text areas UI should display the max size and prevent additional entry.
>
> Proposal is this:
> - Follow the good data dictionary principle where a field name means has a specific meaning and definition that is unambiguous across entities. mostly present in ofbiz
> - Reuse the field names and definition to automatically deduce in user interface the intent of the front end wrt. max sizes and ideally data type.
>
> Harmeet
>
> ----- Original Message -----
> From: "BJ Freeman" <[hidden email]>
> To: [hidden email]
> Sent: Sunday, May 10, 2009 11:05:28 AM GMT -05:00 US/Canada Eastern
> Subject: Re: Field max size based on DB field info
>
> as per the jira this is all controlled by
> modelformfield.java, not the entity field type.
> the Jira was to address changing this.
> the original question was
>
> Does doing this break any models or design goals?
> Is there a reason this DB field info is not used in the ModelFormField.java
>
>
> Harmeet Bedi sent the following on 5/10/2009 7:40 AM:
>> We did some work in this area:
>>
>> The issues were the following
>> 1. If you pass a string that is larger than type of db field, transaction crashes
>> 2. UI forms are not necessary same as db entities. UI forms are persisted through services db entities or services. It is hard to tie UI forms with actual persistence to ensure safety of (1). Best approach may be to have conservative defaults.
>> 3. For text fields and text areas UI should display the max size and prevent additional entry.
>> 4. Concrete DB Info is based on db type as per fieldtype(dbtype).xml
>>
>> There were a couple of realizations.. Ofbiz data dictionary is nicely done. A field usually means the same thing and has same dimension if present in multiple tables. e.g. partyId is same (maxsize 20) and so is comments(maxsize 255). There are very few anomalies. These were
>>
>> # field to list of 'entity.size', if size varies per entity
>> entitysize.accountNumber=EftAccount:255,PartyCarrierAccount:20,PartyGroup:100,PayrollPreference:60
>> entitysize.cardNumber=CreditCard:255,GiftCard:255,GiftCardFulfillment:255,ValueLinkFulfillment:60
>> entitysize.city=PostalAddress:100,ZipSalesRuleLookup:60,ZipSalesTaxLookup:60
>> entitysize.contentId=CommEventContentAssoc:20,Content:20,ContentApproval:20,ContentAssoc:20,ContentAttribute:20,ContentMetaData:20,ContentPurpose:20,ContentRevision:20,ContentRevisionItem:20,ContentRole:20,CustRequestContent:20,OrderContent:20,PartyContent:20,PartyResume:20,ProdConfItemContent:20,ProductCategoryContent:20,ProductContent:20,ServerHit:255,ServerHitBin:255,SubscriptionResource:20,SurveyResponseAnswer:20,WebPage:20,WebSiteContent:20,WebSitePathAlias:20,WebSitePublishPoint:20,WorkEffortContent:20
>> entitysize.countryCode=CountryCapital:20,CountryCode:20,CountryTeleCode:20,TelecomNumber:10
>> entitysize.description=AccommodationClass:255,AccommodationMapType:255,AccommodationSpot:255,AcctgTrans:255,AcctgTransEntry:255,AcctgTransEntryType:255,AcctgTransType:255,Agreement:255,AgreementItemType:255,AgreementTerm:255,AgreementType:255,BenefitType:255,BillingAccount:255,BudgetItemType:255,BudgetReviewResultType:255,BudgetScenario:255,BudgetType:255,CharacterSet:255,CommContentAssocType:255,CommunicationEventPrpTyp:255,CommunicationEventPurpose:255,CommunicationEventType:255,CommunicationEventWorkEff:255,ConfigOptionProductOption:255,ContactList:255,ContactListType:255,ContactMechPurposeType:255,ContactMechType:255,Container:255,ContainerType:255,Content:255,ContentAssocPredicate:255,ContentAssocType:255,ContentOperation:255,ContentPurposeType:255,ContentType:255,CostComponentCalc:255,CostComponentType:255,CurrencyDimension:255,CustRequest:255,CustRequestCategory:255,CustRequestItem:255,CustRequestResolution:255,CustRequestType:255,CustomMethod:255,CustomMethodType:

2
> 55,DataResourceType:255,DataSource:255,DataSourceType:255,DataTemplateType:255,DateDimension:255,DeductionType:255,Deliverable:255,DeliverableType:255,DepreciationMethod:255,DocumentType:255,EmplLeave:255,EmplLeaveType:255,EmplPositionClassType:255,EmplPositionType:255,EmploymentAppSourceType:255,Enumeration:255,EnumerationType:255,Example:255,ExampleFeature:255,ExampleFeatureApplType:255,ExampleItem:255,ExampleType:255,Facility:255,FacilityGroup:255,FacilityGroupType:255,FacilityType:255,FinAccountTransType:255,FinAccountType:255,FixedAssetIdentType:255,FixedAssetProductType:255,FixedAssetStdCostType:255,FixedAssetType:255,GeoAssocType:255,GeoType:255,GlAccount:255,GlAccountClass:255,GlAccountGroup:255,GlAccountGroupType:255,GlAccountType:255,GlFiscalType:255,GlReconciliation:255,GlResourceType:255,GlXbrlClass:255,GoodIdentificationType:255,InventoryItemDetail:255,InventoryItemLabel:255,InventoryItemLabelType:255,InventoryItemType:255,Invoice:255,InvoiceItem:255,InvoiceIt
emT
> ype:255,InvoiceTerm:255,InvoiceType:255,MetaDataPredicate:255,MimeType:255,MrpEventType:255,NeedType:255,OagisMessageErrorInfo:2147483647,OrderAdjustment:255,OrderAdjustmentType:255,OrderBlacklistType:255,OrderContentType:255,OrderItemAssocType:255,OrderItemPriceInfo:255,OrderItemType:255,OrderTerm:255,OrderType:255,Party:2147483647,PartyClassification:255,PartyClassificationGroup:255,PartyClassificationType:255,PartyContentType:255,PartyNeed:255,PartyQualType:255,PartyRelationshipType:255,PartyTimeTracker:60,PartyType:255,PaymentMethod:255,PaymentMethodType:255,PaymentType:255,PerfRatingType:255,PerfReviewItemType:255,PeriodType:255,Picklist:255,PortalPage:255,PortalPortlet:255,PriorityType:255,ProdCatalogCategoryType:255,ProdConfItemContentType:255,Product:255,ProductAssocType:255,ProductCategory:255,ProductCategoryContentType:255,ProductCategoryType:255,ProductConfig:255,ProductConfigConfig:255,ProductConfigItem:255,ProductConfigOption:255,ProductConfigOptionIactn:255,P
rod
> uctContentType:255,ProductEnumerationType:255,ProductFeature:255,ProductFeatureApplType:255,ProductFeatureCategory:255,ProductFeatureGroup:255,ProductFeatureIactnType:255,ProductFeatureType:255,ProductGeo:255,ProductMaintType:255,ProductManufacturingRule:255,ProductMeterType:255,ProductPriceActionType:255,ProductPricePurpose:255,ProductPriceRule:255,ProductPriceType:255,ProductStoreGroup:255,ProductStoreGroupType:255,ProductTag:100,ProductTagFieldAttribute:100,ProductTagStyle:100,ProductType:255,QuantityBreakType:255,Quote:255,QuoteAdjustment:255,QuoteType:255,RateType:255,RejectionReason:255,Requirement:255,RequirementType:255,ResponsibilityType:255,ReturnAdjustment:255,ReturnAdjustmentType:255,ReturnHeaderType:255,ReturnItem:255,ReturnItemType:255,ReturnReason:255,ReturnType:255,RoleType:255,SaleType:255,SalesOpportunity:2147483647,SalesOpportunityHistory:2147483647,SalesOpportunityStage:255,SecurityGroup:255,SecurityPermission:255,SegmentGroup:255,SegmentGroupType:255,S
erv
> erHitType:255,ShipmentBoxType:255,ShipmentContactMechType:255,ShipmentMethodType:255,ShipmentType:255,ShippingDocument:255,ShoppingList:255,ShoppingListType:255,SkillType:255,StatusItem:255,StatusType:255,Subscription:255,SubscriptionResource:255,SubscriptionType:255,SupplierPrefOrder:255,SupplierProductFeature:100,SupplierRatingType:255,Survey:255,SurveyApplType:255,SurveyQuestion:255,SurveyQuestionCategory:255,SurveyQuestionOption:255,SurveyQuestionType:255,Tag:100,TagFieldAttribute:100,TagStyle:100,TaxAuthorityAssocType:255,TaxAuthorityRateProduct:255,TaxAuthorityRateType:255,TechDataCalendar:255,TechDataCalendarExcDay:255,TechDataCalendarExcWeek:255,TechDataCalendarWeek:255,TermType:255,TerminationReason:255,TerminationType:255,Testing:255,TestingNode:255,TestingType:255,TrackingCode:255,TrackingCodeType:255,TrainingClassType:255,UnemploymentClaim:255,Uom:255,UomType:255,UserAgentMethodType:255,UserAgentType:255,UserPrefGroupType:255,VarianceReason:255,VisualTheme:255,
Web

> PreferenceType:255,WebSiteContentType:255,WorkEffort:255,WorkEffortAssocType:255,WorkEffortContentType:255,WorkEffortGoodStandardType:255,WorkEffortPurposeType:255,WorkEffortType:255,WorkReqFulfType:255
>> entitysize.extension=DataTemplateType:60,FacilityContactMech:10,PartyContactMech:255
>> entitysize.idCode=ProductFeature:20,SupplierProductFeature:20,ZipSalesRuleLookup:60
>> entitysize.idValue=FixedAssetIdent:255,GoodIdentification:60
>> entitysize.mapKey=AddressMatchMap:255,ContentAssoc:100,WebSitePathAlias:100
>> entitysize.pinNumber=GiftCard:255,GiftCardFulfillment:255,ValueLinkFulfillment:60
>> entitysize.referenceId=OagisMessageErrorInfo:60,OagisMessageInfo:60,SurveyResponse:255
>> entitysize.serviceName=Content:255,JobSandbox:100,ProductStoreShipmentMeth:255,ServiceSemaphore:100
>> entitysize.sessionId=CatalinaSession:60,Visit:255
>> entitysize.taxable=Product:1,ZipSalesRuleLookup:60
>> entitysize.title=PartyQual:60,ProductStore:100,ProductTag:100,ProductTagFieldAttribute:100,ProductTagStyle:100
>> entitysize.transactionId=OrderHeader:60,PosTerminalLog:20
>>
>>
>>
>> Here is what we did.
>>
>> - Crawled our target database postgres to build columnid to maxsize mapping for all entities and put it into a properties file. From our ofbiz fork late last year there were 1400 column names with with unambiguous maxsize and about 17 ambiguous columns size (as mentioned above). For ambiguous column names we assumed the max size was lower of the possible values. e.g. accountNumber has maxsize 60(from PayrollPreference not EftAccount)
>>
>> - Our UI forms could use default column names and not care about db entities, services perisistence etc.
>> So there if UI had these 3 columns.
>> <field name="partyId"><text ...></field>
>> <field name="comments"><textarea ...></field>
>> <field name="accountNumber"><text ...></field>
>> The model forms take into account that partyId means maxsize 20, comments 255 and accountNumber 60 and the generation is changed accordingly. Properties are cached through UtilProperties(UtilCache) so efficient.
>>
>> The nice thing is that by basing max size on column id, not entity and column id, maxsize value add is more or less transparent.
>>
>> We only auto apply maxsize if form does not explicitly specify. in a small number of cases it is better to override defaults by explicitly specifying. e.g. crawler gave
>> carrierRestrictionDesc=2147483647
>> this is for
>> <field name="carrierRestrictionDesc" type="very-long"></field>
>> This is text type. One could do something more reasonable for Text types.. they a small number in any case.
>>
>>
>> Attached is the file we used to generate. Feel free to use it as you see fit. it generates FieldSize.properties (if there max size per column name is not ambiguous) and FieldSizeAnomaly.properties for columns where data dictionary has anomalous meaning.. (likely bugs)
>>
>> Harmeet
>>
>>
>> ----- Original Message -----
>> From: "Jacques Le Roux" <[hidden email]>
>> To: [hidden email]
>> Sent: Saturday, May 9, 2009 5:56:33 PM GMT -05:00 US/Canada Eastern
>> Subject: Re: Field max size based on DB field info
>>
>> It seems that nothing happenned (no answers, etc.) after this message, please why ?
>>
>> Thanks
>>
>> Jacques
>>
>> From: "BJ Freeman" <[hidden email]>
>>> Up till now I assumed the DB field info was fed back into the entities
>>> when field size as defined.
>>> questions:
>>> Does doing this break any models or design goals?
>>> Is there a reason this DB field info is not used in the ModelFormField.java
>>>
>

--
BJ Freeman
http://www.businessesnetwork.com/automation
http://bjfreeman.elance.com
http://www.linkedin.com/profile?viewProfile=&key=1237480&locale=en_US&trk=tab_pro
Systems Integrator.

Harmeet Bedi

Re: Field max size based on DB field info

I fell UI tied directly to db entity is too much coupling. Interaction designers need to model based on end users, db model needs to play nice with normal forms. Intermediate services/ecas etc. would map the two.
Coupling db model and ui would constrain.. I do see need to reuse metadata from entities to make things easier to develop.. but feel loose/indirect coupling is better than tight db-ui coupling.

CSS and % not fixed is very good. I was mostly concerned about max length, not display length. For display length.. i think evil is having hardcoded numeric sizes.

Harmeet

----- Original Message -----
From: "BJ Freeman" <[hidden email]>
To: [hidden email]
Sent: Sunday, May 10, 2009 12:06:18 PM GMT -05:00 US/Canada Eastern
Subject: Re: Field max size based on DB field info

I understand you point of view about not tying a UI field to a form
however the basic part of ofbiz design is that you don't have to
maintain the UI when you add to the entity.
The whole ofbiz design if focused that if you maintain the entity the
storage and UI are automatically updated.
In other words it make maintaining of the system easier.

to address the make field length over run if you design a hard coded UI
with say 60 as the length because the is the DB you are using, it is not
portable to say a DB that max length is 30.
The field length should not be made at the UI design level.
Under the proposal I thinking about, the UI field lengths should be
based on CSS and % not fixed.
As an example with tables, they adjust as the web browser is resized.
so must the Fields adjust as the browser it resized and or the fields
postion is adjusted to keep in in the viewer vision.

So some where in the rendering process of all handlers, should be the
method of adjusting entity fields to UI fields so the UI fields are
presentable, but limit the UI feilds so they are no longer than the
entity field types for that db.

I believe you and my goal are the same, have a presentable UI.
it is the method of how to do it that we differ.

Harmeet Bedi sent the following on 5/10/2009 8:23 AM:

--
BJ Freeman
http://www.businessesnetwork.com/automation
http://bjfreeman.elance.com
http://www.linkedin.com/profile?viewProfile=&key=1237480&locale=en_US&trk=tab_pro
Systems Integrator.

BJ Freeman

Re: Field max size based on DB field info

In reply to this post by BJ Freeman

The only constraint would be maximum length allowed.
but for the UI designer to get a Max length and set the field length to
less than the max is reasonable.
The question is how can the UI designer pass the field length
information down to the rendering handlers to give the flexibility.
as far as location this is already available thru CSS which makes it
loosely coupled.

This brings us back to the orginal
as per the jira this is all controlled by
modelformfield.java, not the entity field type.
the Jira was to address changing this.
the original question was

Does doing this break any models or design goals?
Is there a reason this DB field info is not used in the ModelFormField.java

Harmeet Bedi sent the following on 5/10/2009 9:29 AM:

> I fell UI tied directly to db entity is too much coupling. Interaction designers need to model based on end users, db model needs to play nice with normal forms. Intermediate services/ecas etc. would map the two.
> Coupling db model and ui would constrain.. I do see need to reuse metadata from entities to make things easier to develop.. but feel loose/indirect coupling is better than tight db-ui coupling.
>
> CSS and % not fixed is very good. I was mostly concerned about max length, not display length. For display length.. i think evil is having hardcoded numeric sizes.
>
> Harmeet
>
>
>
> ----- Original Message -----
> From: "BJ Freeman" <[hidden email]>
> To: [hidden email]
> Sent: Sunday, May 10, 2009 12:06:18 PM GMT -05:00 US/Canada Eastern
> Subject: Re: Field max size based on DB field info
>
> I understand you point of view about not tying a UI field to a form
> however the basic part of ofbiz design is that you don't have to
> maintain the UI when you add to the entity.
> The whole ofbiz design if focused that if you maintain the entity the
> storage and UI are automatically updated.
> In other words it make maintaining of the system easier.
>
> to address the make field length over run if you design a hard coded UI
> with say 60 as the length because the is the DB you are using, it is not
> portable to say a DB that max length is 30.
> The field length should not be made at the UI design level.
> Under the proposal I thinking about, the UI field lengths should be
> based on CSS and % not fixed.
> As an example with tables, they adjust as the web browser is resized.
> so must the Fields adjust as the browser it resized and or the fields
> postion is adjusted to keep in in the viewer vision.
>
> So some where in the rendering process of all handlers, should be the
> method of adjusting entity fields to UI fields so the UI fields are
> presentable, but limit the UI feilds so they are no longer than the
> entity field types for that db.
>
> I believe you and my goal are the same, have a presentable UI.
> it is the method of how to do it that we differ.
>
>
>
>
>
>
> Harmeet Bedi sent the following on 5/10/2009 8:23 AM:
>> I feel tying ui forms to persistent entities has some issues
>> - Front end may call more than one entity.
>> - It is hard to trace front end to all possible services and entity it may reference.
>> - It is not necessary that a UI form may be tied to an entity.
>>
>> However tying front end to have reasonable defaults is a good thing from UI as
>> - safer: If you pass a string that is larger than type of db field, transaction crashes
>> - usability: For text fields and text areas UI should display the max size and prevent additional entry.
>>
>> Proposal is this:
>> - Follow the good data dictionary principle where a field name means has a specific meaning and definition that is unambiguous across entities. mostly present in ofbiz
>> - Reuse the field names and definition to automatically deduce in user interface the intent of the front end wrt. max sizes and ideally data type.
>>
>> Harmeet
>>
>> ----- Original Message -----
>> From: "BJ Freeman" <[hidden email]>
>> To: [hidden email]
>> Sent: Sunday, May 10, 2009 11:05:28 AM GMT -05:00 US/Canada Eastern
>> Subject: Re: Field max size based on DB field info
>>
>> as per the jira this is all controlled by
>> modelformfield.java, not the entity field type.
>> the Jira was to address changing this.
>> the original question was
>>
>> Does doing this break any models or design goals?
>> Is there a reason this DB field info is not used in the ModelFormField.java
>>
>>
>> Harmeet Bedi sent the following on 5/10/2009 7:40 AM:
>>> We did some work in this area:
>>>
>>> The issues were the following
>>> 1. If you pass a string that is larger than type of db field, transaction crashes
>>> 2. UI forms are not necessary same as db entities. UI forms are persisted through services db entities or services. It is hard to tie UI forms with actual persistence to ensure safety of (1). Best approach may be to have conservative defaults.
>>> 3. For text fields and text areas UI should display the max size and prevent additional entry.
>>> 4. Concrete DB Info is based on db type as per fieldtype(dbtype).xml
>>>
>>> There were a couple of realizations.. Ofbiz data dictionary is nicely done. A field usually means the same thing and has same dimension if present in multiple tables. e.g. partyId is same (maxsize 20) and so is comments(maxsize 255). There are very few anomalies. These were
>>>
>>> # field to list of 'entity.size', if size varies per entity
>>> entitysize.accountNumber=EftAccount:255,PartyCarrierAccount:20,PartyGroup:100,PayrollPreference:60
>>> entitysize.cardNumber=CreditCard:255,GiftCard:255,GiftCardFulfillment:255,ValueLinkFulfillment:60
>>> entitysize.city=PostalAddress:100,ZipSalesRuleLookup:60,ZipSalesTaxLookup:60
>>> entitysize.contentId=CommEventContentAssoc:20,Content:20,ContentApproval:20,ContentAssoc:20,ContentAttribute:20,ContentMetaData:20,ContentPurpose:20,ContentRevision:20,ContentRevisionItem:20,ContentRole:20,CustRequestContent:20,OrderContent:20,PartyContent:20,PartyResume:20,ProdConfItemContent:20,ProductCategoryContent:20,ProductContent:20,ServerHit:255,ServerHitBin:255,SubscriptionResource:20,SurveyResponseAnswer:20,WebPage:20,WebSiteContent:20,WebSitePathAlias:20,WebSitePublishPoint:20,WorkEffortContent:20
>>> entitysize.countryCode=CountryCapital:20,CountryCode:20,CountryTeleCode:20,TelecomNumber:10
>>> entitysize.description=AccommodationClass:255,AccommodationMapType:255,AccommodationSpot:255,AcctgTrans:255,AcctgTransEntry:255,AcctgTransEntryType:255,AcctgTransType:255,Agreement:255,AgreementItemType:255,AgreementTerm:255,AgreementType:255,BenefitType:255,BillingAccount:255,BudgetItemType:255,BudgetReviewResultType:255,BudgetScenario:255,BudgetType:255,CharacterSet:255,CommContentAssocType:255,CommunicationEventPrpTyp:255,CommunicationEventPurpose:255,CommunicationEventType:255,CommunicationEventWorkEff:255,ConfigOptionProductOption:255,ContactList:255,ContactListType:255,ContactMechPurposeType:255,ContactMechType:255,Container:255,ContainerType:255,Content:255,ContentAssocPredicate:255,ContentAssocType:255,ContentOperation:255,ContentPurposeType:255,ContentType:255,CostComponentCalc:255,CostComponentType:255,CurrencyDimension:255,CustRequest:255,CustRequestCategory:255,CustRequestItem:255,CustRequestResolution:255,CustRequestType:255,CustomMethod:255,CustomMethodType

:
> 2
>> 55,DataResourceType:255,DataSource:255,DataSourceType:255,DataTemplateType:255,DateDimension:255,DeductionType:255,Deliverable:255,DeliverableType:255,DepreciationMethod:255,DocumentType:255,EmplLeave:255,EmplLeaveType:255,EmplPositionClassType:255,EmplPositionType:255,EmploymentAppSourceType:255,Enumeration:255,EnumerationType:255,Example:255,ExampleFeature:255,ExampleFeatureApplType:255,ExampleItem:255,ExampleType:255,Facility:255,FacilityGroup:255,FacilityGroupType:255,FacilityType:255,FinAccountTransType:255,FinAccountType:255,FixedAssetIdentType:255,FixedAssetProductType:255,FixedAssetStdCostType:255,FixedAssetType:255,GeoAssocType:255,GeoType:255,GlAccount:255,GlAccountClass:255,GlAccountGroup:255,GlAccountGroupType:255,GlAccountType:255,GlFiscalType:255,GlReconciliation:255,GlResourceType:255,GlXbrlClass:255,GoodIdentificationType:255,InventoryItemDetail:255,InventoryItemLabel:255,InventoryItemLabelType:255,InventoryItemType:255,Invoice:255,InvoiceItem:255,InvoiceI
t
> emT
>> ype:255,InvoiceTerm:255,InvoiceType:255,MetaDataPredicate:255,MimeType:255,MrpEventType:255,NeedType:255,OagisMessageErrorInfo:2147483647,OrderAdjustment:255,OrderAdjustmentType:255,OrderBlacklistType:255,OrderContentType:255,OrderItemAssocType:255,OrderItemPriceInfo:255,OrderItemType:255,OrderTerm:255,OrderType:255,Party:2147483647,PartyClassification:255,PartyClassificationGroup:255,PartyClassificationType:255,PartyContentType:255,PartyNeed:255,PartyQualType:255,PartyRelationshipType:255,PartyTimeTracker:60,PartyType:255,PaymentMethod:255,PaymentMethodType:255,PaymentType:255,PerfRatingType:255,PerfReviewItemType:255,PeriodType:255,Picklist:255,PortalPage:255,PortalPortlet:255,PriorityType:255,ProdCatalogCategoryType:255,ProdConfItemContentType:255,Product:255,ProductAssocType:255,ProductCategory:255,ProductCategoryContentType:255,ProductCategoryType:255,ProductConfig:255,ProductConfigConfig:255,ProductConfigItem:255,ProductConfigOption:255,ProductConfigOptionIactn:255,
P
> rod
>> uctContentType:255,ProductEnumerationType:255,ProductFeature:255,ProductFeatureApplType:255,ProductFeatureCategory:255,ProductFeatureGroup:255,ProductFeatureIactnType:255,ProductFeatureType:255,ProductGeo:255,ProductMaintType:255,ProductManufacturingRule:255,ProductMeterType:255,ProductPriceActionType:255,ProductPricePurpose:255,ProductPriceRule:255,ProductPriceType:255,ProductStoreGroup:255,ProductStoreGroupType:255,ProductTag:100,ProductTagFieldAttribute:100,ProductTagStyle:100,ProductType:255,QuantityBreakType:255,Quote:255,QuoteAdjustment:255,QuoteType:255,RateType:255,RejectionReason:255,Requirement:255,RequirementType:255,ResponsibilityType:255,ReturnAdjustment:255,ReturnAdjustmentType:255,ReturnHeaderType:255,ReturnItem:255,ReturnItemType:255,ReturnReason:255,ReturnType:255,RoleType:255,SaleType:255,SalesOpportunity:2147483647,SalesOpportunityHistory:2147483647,SalesOpportunityStage:255,SecurityGroup:255,SecurityPermission:255,SegmentGroup:255,SegmentGroupType:255,
S
> erv
>> erHitType:255,ShipmentBoxType:255,ShipmentContactMechType:255,ShipmentMethodType:255,ShipmentType:255,ShippingDocument:255,ShoppingList:255,ShoppingListType:255,SkillType:255,StatusItem:255,StatusType:255,Subscription:255,SubscriptionResource:255,SubscriptionType:255,SupplierPrefOrder:255,SupplierProductFeature:100,SupplierRatingType:255,Survey:255,SurveyApplType:255,SurveyQuestion:255,SurveyQuestionCategory:255,SurveyQuestionOption:255,SurveyQuestionType:255,Tag:100,TagFieldAttribute:100,TagStyle:100,TaxAuthorityAssocType:255,TaxAuthorityRateProduct:255,TaxAuthorityRateType:255,TechDataCalendar:255,TechDataCalendarExcDay:255,TechDataCalendarExcWeek:255,TechDataCalendarWeek:255,TermType:255,TerminationReason:255,TerminationType:255,Testing:255,TestingNode:255,TestingType:255,TrackingCode:255,TrackingCodeType:255,TrainingClassType:255,UnemploymentClaim:255,Uom:255,UomType:255,UserAgentMethodType:255,UserAgentType:255,UserPrefGroupType:255,VarianceReason:255,VisualTheme:255
,

> Web
>> PreferenceType:255,WebSiteContentType:255,WorkEffort:255,WorkEffortAssocType:255,WorkEffortContentType:255,WorkEffortGoodStandardType:255,WorkEffortPurposeType:255,WorkEffortType:255,WorkReqFulfType:255
>>> entitysize.extension=DataTemplateType:60,FacilityContactMech:10,PartyContactMech:255
>>> entitysize.idCode=ProductFeature:20,SupplierProductFeature:20,ZipSalesRuleLookup:60
>>> entitysize.idValue=FixedAssetIdent:255,GoodIdentification:60
>>> entitysize.mapKey=AddressMatchMap:255,ContentAssoc:100,WebSitePathAlias:100
>>> entitysize.pinNumber=GiftCard:255,GiftCardFulfillment:255,ValueLinkFulfillment:60
>>> entitysize.referenceId=OagisMessageErrorInfo:60,OagisMessageInfo:60,SurveyResponse:255
>>> entitysize.serviceName=Content:255,JobSandbox:100,ProductStoreShipmentMeth:255,ServiceSemaphore:100
>>> entitysize.sessionId=CatalinaSession:60,Visit:255
>>> entitysize.taxable=Product:1,ZipSalesRuleLookup:60
>>> entitysize.title=PartyQual:60,ProductStore:100,ProductTag:100,ProductTagFieldAttribute:100,ProductTagStyle:100
>>> entitysize.transactionId=OrderHeader:60,PosTerminalLog:20
>>>
>>>
>>>
>>> Here is what we did.
>>>
>>> - Crawled our target database postgres to build columnid to maxsize mapping for all entities and put it into a properties file. From our ofbiz fork late last year there were 1400 column names with with unambiguous maxsize and about 17 ambiguous columns size (as mentioned above). For ambiguous column names we assumed the max size was lower of the possible values. e.g. accountNumber has maxsize 60(from PayrollPreference not EftAccount)
>>>
>>> - Our UI forms could use default column names and not care about db entities, services perisistence etc.
>>> So there if UI had these 3 columns.
>>> <field name="partyId"><text ...></field>
>>> <field name="comments"><textarea ...></field>
>>> <field name="accountNumber"><text ...></field>
>>> The model forms take into account that partyId means maxsize 20, comments 255 and accountNumber 60 and the generation is changed accordingly. Properties are cached through UtilProperties(UtilCache) so efficient.
>>>
>>> The nice thing is that by basing max size on column id, not entity and column id, maxsize value add is more or less transparent.
>>>
>>> We only auto apply maxsize if form does not explicitly specify. in a small number of cases it is better to override defaults by explicitly specifying. e.g. crawler gave
>>> carrierRestrictionDesc=2147483647
>>> this is for
>>> <field name="carrierRestrictionDesc" type="very-long"></field>
>>> This is text type. One could do something more reasonable for Text types.. they a small number in any case.
>>>
>>>
>>> Attached is the file we used to generate. Feel free to use it as you see fit. it generates FieldSize.properties (if there max size per column name is not ambiguous) and FieldSizeAnomaly.properties for columns where data dictionary has anomalous meaning.. (likely bugs)
>>>
>>> Harmeet
>>>
>>>
>>> ----- Original Message -----
>>> From: "Jacques Le Roux" <[hidden email]>
>>> To: [hidden email]
>>> Sent: Saturday, May 9, 2009 5:56:33 PM GMT -05:00 US/Canada Eastern
>>> Subject: Re: Field max size based on DB field info
>>>
>>> It seems that nothing happenned (no answers, etc.) after this message, please why ?
>>>
>>> Thanks
>>>
>>> Jacques
>>>
>>> From: "BJ Freeman" <[hidden email]>
>>>> Up till now I assumed the DB field info was fed back into the entities
>>>> when field size as defined.
>>>> questions:
>>>> Does doing this break any models or design goals?
>>>> Is there a reason this DB field info is not used in the ModelFormField.java
>>>>
>

--
BJ Freeman
http://www.businessesnetwork.com/automation
http://bjfreeman.elance.com
http://www.linkedin.com/profile?viewProfile=&key=1237480&locale=en_US&trk=tab_pro
Systems Integrator.

BJ Freeman

Re: Field max size based on DB field info

In reply to this post by BJ Freeman

to answer the question about how to pass the information down
in another jira Hans mentioned that Japaco was working on the freemaker
macros.
Not sure what all that means yet, have to take some time and read up on it
see if there is anything there that can be leveaged

BJ Freeman sent the following on 5/10/2009 9:48 AM:

> The only constraint would be maximum length allowed.
> but for the UI designer to get a Max length and set the field length to
> less than the max is reasonable.
> The question is how can the UI designer pass the field length
> information down to the rendering handlers to give the flexibility.
> as far as location this is already available thru CSS which makes it
> loosely coupled.
>
> This brings us back to the orginal
> as per the jira this is all controlled by
> modelformfield.java, not the entity field type.
> the Jira was to address changing this.
> the original question was
>
> Does doing this break any models or design goals?
> Is there a reason this DB field info is not used in the ModelFormField.java
>
>
>
> Harmeet Bedi sent the following on 5/10/2009 9:29 AM:
>> I fell UI tied directly to db entity is too much coupling. Interaction designers need to model based on end users, db model needs to play nice with normal forms. Intermediate services/ecas etc. would map the two.
>> Coupling db model and ui would constrain.. I do see need to reuse metadata from entities to make things easier to develop.. but feel loose/indirect coupling is better than tight db-ui coupling.
>>
>> CSS and % not fixed is very good. I was mostly concerned about max length, not display length. For display length.. i think evil is having hardcoded numeric sizes.
>>
>> Harmeet
>>
>>
>>
>> ----- Original Message -----
>> From: "BJ Freeman" <[hidden email]>
>> To: [hidden email]
>> Sent: Sunday, May 10, 2009 12:06:18 PM GMT -05:00 US/Canada Eastern
>> Subject: Re: Field max size based on DB field info
>>
>> I understand you point of view about not tying a UI field to a form
>> however the basic part of ofbiz design is that you don't have to
>> maintain the UI when you add to the entity.
>> The whole ofbiz design if focused that if you maintain the entity the
>> storage and UI are automatically updated.
>> In other words it make maintaining of the system easier.
>>
>> to address the make field length over run if you design a hard coded UI
>> with say 60 as the length because the is the DB you are using, it is not
>> portable to say a DB that max length is 30.
>> The field length should not be made at the UI design level.
>> Under the proposal I thinking about, the UI field lengths should be
>> based on CSS and % not fixed.
>> As an example with tables, they adjust as the web browser is resized.
>> so must the Fields adjust as the browser it resized and or the fields
>> postion is adjusted to keep in in the viewer vision.
>>
>> So some where in the rendering process of all handlers, should be the
>> method of adjusting entity fields to UI fields so the UI fields are
>> presentable, but limit the UI feilds so they are no longer than the
>> entity field types for that db.
>>
>> I believe you and my goal are the same, have a presentable UI.
>> it is the method of how to do it that we differ.
>>
>>
>>
>>
>>
>>
>> Harmeet Bedi sent the following on 5/10/2009 8:23 AM:
>>> I feel tying ui forms to persistent entities has some issues
>>> - Front end may call more than one entity.
>>> - It is hard to trace front end to all possible services and entity it may reference.
>>> - It is not necessary that a UI form may be tied to an entity.
>>>
>>> However tying front end to have reasonable defaults is a good thing from UI as
>>> - safer: If you pass a string that is larger than type of db field, transaction crashes
>>> - usability: For text fields and text areas UI should display the max size and prevent additional entry.
>>>
>>> Proposal is this:
>>> - Follow the good data dictionary principle where a field name means has a specific meaning and definition that is unambiguous across entities. mostly present in ofbiz
>>> - Reuse the field names and definition to automatically deduce in user interface the intent of the front end wrt. max sizes and ideally data type.
>>>
>>> Harmeet
>>>
>>> ----- Original Message -----
>>> From: "BJ Freeman" <[hidden email]>
>>> To: [hidden email]
>>> Sent: Sunday, May 10, 2009 11:05:28 AM GMT -05:00 US/Canada Eastern
>>> Subject: Re: Field max size based on DB field info
>>>
>>> as per the jira this is all controlled by
>>> modelformfield.java, not the entity field type.
>>> the Jira was to address changing this.
>>> the original question was
>>>
>>> Does doing this break any models or design goals?
>>> Is there a reason this DB field info is not used in the ModelFormField.java
>>>
>>>
>>> Harmeet Bedi sent the following on 5/10/2009 7:40 AM:
>>>> We did some work in this area:
>>>>
>>>> The issues were the following
>>>> 1. If you pass a string that is larger than type of db field, transaction crashes
>>>> 2. UI forms are not necessary same as db entities. UI forms are persisted through services db entities or services. It is hard to tie UI forms with actual persistence to ensure safety of (1). Best approach may be to have conservative defaults.
>>>> 3. For text fields and text areas UI should display the max size and prevent additional entry.
>>>> 4. Concrete DB Info is based on db type as per fieldtype(dbtype).xml
>>>>
>>>> There were a couple of realizations.. Ofbiz data dictionary is nicely done. A field usually means the same thing and has same dimension if present in multiple tables. e.g. partyId is same (maxsize 20) and so is comments(maxsize 255). There are very few anomalies. These were
>>>>
>>>> # field to list of 'entity.size', if size varies per entity
>>>> entitysize.accountNumber=EftAccount:255,PartyCarrierAccount:20,PartyGroup:100,PayrollPreference:60
>>>> entitysize.cardNumber=CreditCard:255,GiftCard:255,GiftCardFulfillment:255,ValueLinkFulfillment:60
>>>> entitysize.city=PostalAddress:100,ZipSalesRuleLookup:60,ZipSalesTaxLookup:60
>>>> entitysize.contentId=CommEventContentAssoc:20,Content:20,ContentApproval:20,ContentAssoc:20,ContentAttribute:20,ContentMetaData:20,ContentPurpose:20,ContentRevision:20,ContentRevisionItem:20,ContentRole:20,CustRequestContent:20,OrderContent:20,PartyContent:20,PartyResume:20,ProdConfItemContent:20,ProductCategoryContent:20,ProductContent:20,ServerHit:255,ServerHitBin:255,SubscriptionResource:20,SurveyResponseAnswer:20,WebPage:20,WebSiteContent:20,WebSitePathAlias:20,WebSitePublishPoint:20,WorkEffortContent:20
>>>> entitysize.countryCode=CountryCapital:20,CountryCode:20,CountryTeleCode:20,TelecomNumber:10
>>>> entitysize.description=AccommodationClass:255,AccommodationMapType:255,AccommodationSpot:255,AcctgTrans:255,AcctgTransEntry:255,AcctgTransEntryType:255,AcctgTransType:255,Agreement:255,AgreementItemType:255,AgreementTerm:255,AgreementType:255,BenefitType:255,BillingAccount:255,BudgetItemType:255,BudgetReviewResultType:255,BudgetScenario:255,BudgetType:255,CharacterSet:255,CommContentAssocType:255,CommunicationEventPrpTyp:255,CommunicationEventPurpose:255,CommunicationEventType:255,CommunicationEventWorkEff:255,ConfigOptionProductOption:255,ContactList:255,ContactListType:255,ContactMechPurposeType:255,ContactMechType:255,Container:255,ContainerType:255,Content:255,ContentAssocPredicate:255,ContentAssocType:255,ContentOperation:255,ContentPurposeType:255,ContentType:255,CostComponentCalc:255,CostComponentType:255,CurrencyDimension:255,CustRequest:255,CustRequestCategory:255,CustRequestItem:255,CustRequestResolution:255,CustRequestType:255,CustomMethod:255,CustomMethodTyp

e
> :
>> 2
>>> 55,DataResourceType:255,DataSource:255,DataSourceType:255,DataTemplateType:255,DateDimension:255,DeductionType:255,Deliverable:255,DeliverableType:255,DepreciationMethod:255,DocumentType:255,EmplLeave:255,EmplLeaveType:255,EmplPositionClassType:255,EmplPositionType:255,EmploymentAppSourceType:255,Enumeration:255,EnumerationType:255,Example:255,ExampleFeature:255,ExampleFeatureApplType:255,ExampleItem:255,ExampleType:255,Facility:255,FacilityGroup:255,FacilityGroupType:255,FacilityType:255,FinAccountTransType:255,FinAccountType:255,FixedAssetIdentType:255,FixedAssetProductType:255,FixedAssetStdCostType:255,FixedAssetType:255,GeoAssocType:255,GeoType:255,GlAccount:255,GlAccountClass:255,GlAccountGroup:255,GlAccountGroupType:255,GlAccountType:255,GlFiscalType:255,GlReconciliation:255,GlResourceType:255,GlXbrlClass:255,GoodIdentificationType:255,InventoryItemDetail:255,InventoryItemLabel:255,InventoryItemLabelType:255,InventoryItemType:255,Invoice:255,InvoiceItem:255,Invoice
I
> t
>> emT
>>> ype:255,InvoiceTerm:255,InvoiceType:255,MetaDataPredicate:255,MimeType:255,MrpEventType:255,NeedType:255,OagisMessageErrorInfo:2147483647,OrderAdjustment:255,OrderAdjustmentType:255,OrderBlacklistType:255,OrderContentType:255,OrderItemAssocType:255,OrderItemPriceInfo:255,OrderItemType:255,OrderTerm:255,OrderType:255,Party:2147483647,PartyClassification:255,PartyClassificationGroup:255,PartyClassificationType:255,PartyContentType:255,PartyNeed:255,PartyQualType:255,PartyRelationshipType:255,PartyTimeTracker:60,PartyType:255,PaymentMethod:255,PaymentMethodType:255,PaymentType:255,PerfRatingType:255,PerfReviewItemType:255,PeriodType:255,Picklist:255,PortalPage:255,PortalPortlet:255,PriorityType:255,ProdCatalogCategoryType:255,ProdConfItemContentType:255,Product:255,ProductAssocType:255,ProductCategory:255,ProductCategoryContentType:255,ProductCategoryType:255,ProductConfig:255,ProductConfigConfig:255,ProductConfigItem:255,ProductConfigOption:255,ProductConfigOptionIactn:255
,
> P
>> rod
>>> uctContentType:255,ProductEnumerationType:255,ProductFeature:255,ProductFeatureApplType:255,ProductFeatureCategory:255,ProductFeatureGroup:255,ProductFeatureIactnType:255,ProductFeatureType:255,ProductGeo:255,ProductMaintType:255,ProductManufacturingRule:255,ProductMeterType:255,ProductPriceActionType:255,ProductPricePurpose:255,ProductPriceRule:255,ProductPriceType:255,ProductStoreGroup:255,ProductStoreGroupType:255,ProductTag:100,ProductTagFieldAttribute:100,ProductTagStyle:100,ProductType:255,QuantityBreakType:255,Quote:255,QuoteAdjustment:255,QuoteType:255,RateType:255,RejectionReason:255,Requirement:255,RequirementType:255,ResponsibilityType:255,ReturnAdjustment:255,ReturnAdjustmentType:255,ReturnHeaderType:255,ReturnItem:255,ReturnItemType:255,ReturnReason:255,ReturnType:255,RoleType:255,SaleType:255,SalesOpportunity:2147483647,SalesOpportunityHistory:2147483647,SalesOpportunityStage:255,SecurityGroup:255,SecurityPermission:255,SegmentGroup:255,SegmentGroupType:255
,
> S
>> erv
>>> erHitType:255,ShipmentBoxType:255,ShipmentContactMechType:255,ShipmentMethodType:255,ShipmentType:255,ShippingDocument:255,ShoppingList:255,ShoppingListType:255,SkillType:255,StatusItem:255,StatusType:255,Subscription:255,SubscriptionResource:255,SubscriptionType:255,SupplierPrefOrder:255,SupplierProductFeature:100,SupplierRatingType:255,Survey:255,SurveyApplType:255,SurveyQuestion:255,SurveyQuestionCategory:255,SurveyQuestionOption:255,SurveyQuestionType:255,Tag:100,TagFieldAttribute:100,TagStyle:100,TaxAuthorityAssocType:255,TaxAuthorityRateProduct:255,TaxAuthorityRateType:255,TechDataCalendar:255,TechDataCalendarExcDay:255,TechDataCalendarExcWeek:255,TechDataCalendarWeek:255,TermType:255,TerminationReason:255,TerminationType:255,Testing:255,TestingNode:255,TestingType:255,TrackingCode:255,TrackingCodeType:255,TrainingClassType:255,UnemploymentClaim:255,Uom:255,UomType:255,UserAgentMethodType:255,UserAgentType:255,UserPrefGroupType:255,VarianceReason:255,VisualTheme:25
5

> ,
>> Web
>>> PreferenceType:255,WebSiteContentType:255,WorkEffort:255,WorkEffortAssocType:255,WorkEffortContentType:255,WorkEffortGoodStandardType:255,WorkEffortPurposeType:255,WorkEffortType:255,WorkReqFulfType:255
>>>> entitysize.extension=DataTemplateType:60,FacilityContactMech:10,PartyContactMech:255
>>>> entitysize.idCode=ProductFeature:20,SupplierProductFeature:20,ZipSalesRuleLookup:60
>>>> entitysize.idValue=FixedAssetIdent:255,GoodIdentification:60
>>>> entitysize.mapKey=AddressMatchMap:255,ContentAssoc:100,WebSitePathAlias:100
>>>> entitysize.pinNumber=GiftCard:255,GiftCardFulfillment:255,ValueLinkFulfillment:60
>>>> entitysize.referenceId=OagisMessageErrorInfo:60,OagisMessageInfo:60,SurveyResponse:255
>>>> entitysize.serviceName=Content:255,JobSandbox:100,ProductStoreShipmentMeth:255,ServiceSemaphore:100
>>>> entitysize.sessionId=CatalinaSession:60,Visit:255
>>>> entitysize.taxable=Product:1,ZipSalesRuleLookup:60
>>>> entitysize.title=PartyQual:60,ProductStore:100,ProductTag:100,ProductTagFieldAttribute:100,ProductTagStyle:100
>>>> entitysize.transactionId=OrderHeader:60,PosTerminalLog:20
>>>>
>>>>
>>>>
>>>> Here is what we did.
>>>>
>>>> - Crawled our target database postgres to build columnid to maxsize mapping for all entities and put it into a properties file. From our ofbiz fork late last year there were 1400 column names with with unambiguous maxsize and about 17 ambiguous columns size (as mentioned above). For ambiguous column names we assumed the max size was lower of the possible values. e.g. accountNumber has maxsize 60(from PayrollPreference not EftAccount)
>>>>
>>>> - Our UI forms could use default column names and not care about db entities, services perisistence etc.
>>>> So there if UI had these 3 columns.
>>>> <field name="partyId"><text ...></field>
>>>> <field name="comments"><textarea ...></field>
>>>> <field name="accountNumber"><text ...></field>
>>>> The model forms take into account that partyId means maxsize 20, comments 255 and accountNumber 60 and the generation is changed accordingly. Properties are cached through UtilProperties(UtilCache) so efficient.
>>>>
>>>> The nice thing is that by basing max size on column id, not entity and column id, maxsize value add is more or less transparent.
>>>>
>>>> We only auto apply maxsize if form does not explicitly specify. in a small number of cases it is better to override defaults by explicitly specifying. e.g. crawler gave
>>>> carrierRestrictionDesc=2147483647
>>>> this is for
>>>> <field name="carrierRestrictionDesc" type="very-long"></field>
>>>> This is text type. One could do something more reasonable for Text types.. they a small number in any case.
>>>>
>>>>
>>>> Attached is the file we used to generate. Feel free to use it as you see fit. it generates FieldSize.properties (if there max size per column name is not ambiguous) and FieldSizeAnomaly.properties for columns where data dictionary has anomalous meaning.. (likely bugs)
>>>>
>>>> Harmeet
>>>>
>>>>
>>>> ----- Original Message -----
>>>> From: "Jacques Le Roux" <[hidden email]>
>>>> To: [hidden email]
>>>> Sent: Saturday, May 9, 2009 5:56:33 PM GMT -05:00 US/Canada Eastern
>>>> Subject: Re: Field max size based on DB field info
>>>>
>>>> It seems that nothing happenned (no answers, etc.) after this message, please why ?
>>>>
>>>> Thanks
>>>>
>>>> Jacques
>>>>
>>>> From: "BJ Freeman" <[hidden email]>
>>>>> Up till now I assumed the DB field info was fed back into the entities
>>>>> when field size as defined.
>>>>> questions:
>>>>> Does doing this break any models or design goals?
>>>>> Is there a reason this DB field info is not used in the ModelFormField.java
>>>>>
>

--
BJ Freeman
http://www.businessesnetwork.com/automation
http://bjfreeman.elance.com
http://www.linkedin.com/profile?viewProfile=&key=1237480&locale=en_US&trk=tab_pro
Systems Integrator.