Dev - change a few field types

[Si Chen-2]

Hi everybody -

Just wanted to confirm if it'd be OK to change the following field types:

InventoryItem.unitCost and CostCompnent.cost to "floating-point":
because these fields may be calculated, and we need maximum precision
stored in database.  Should not affect Java or minilang code.

WorkEffort.description and CustRequest.description to "very-long":
because they're used for descriptive entries, 255 chars is sometimes not
enough.  Again, should only affect database field and not Java or minilang.

Si

 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

[David E. Jones]

Si Chen wrote:
> Hi everybody -
>
> Just wanted to confirm if it'd be OK to change the following field types:
>
> InventoryItem.unitCost and CostCompnent.cost to "floating-point":
> because these fields may be calculated, and we need maximum precision
> stored in database.  Should not affect Java or minilang code.

These might be okay, but I want to note for everyone that I don't like using floating-point in general for currency related values. These aren't really "final" values so are a very different case, and this might be the best way to go.

> WorkEffort.description and CustRequest.description to "very-long":
> because they're used for descriptive entries, 255 chars is sometimes not
> enough.  Again, should only affect database field and not Java or minilang.

I'm not sure about the WorkEffort.description change... perhaps so, but I don't like it. What would be the reason for breaking the pattern elsewhere here... or in other words how is the WorkEffort description different than other descriptions in the system?

For the CustRequest.description I'd say that this is definitely a bad idea. The intent of the CustRequest design is that the details do _not_ go in the CustRequest entry... they go in the CustRequestItem, specifically in the "story" field which is a very-long.

-David

 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

[Si Chen-2]

Hi David,

1.   I don't love "floating-point" either.  Should make a new fieldtype now for say DECIMAL(18,10).  Or we can just use floating-point for now and change it later.

2.  Is there a field for recording detailed information about a WorkEffort, similar to CustRequestItem?

3.  Ok, I won't make it for CustRequest.  Thanks for pointing that out.

Si

David E. Jones wrote:

Si Chen wrote:
  

Hi everybody -

Just wanted to confirm if it'd be OK to change the following field types:

InventoryItem.unitCost and CostCompnent.cost to "floating-point": 
because these fields may be calculated, and we need maximum precision 
stored in database.  Should not affect Java or minilang code.
    

These might be okay, but I want to note for everyone that I don't like using floating-point in general for currency related values. These aren't really "final" values so are a very different case, and this might be the best way to go.

  

WorkEffort.description and CustRequest.description to "very-long": 
because they're used for descriptive entries, 255 chars is sometimes not 
enough.  Again, should only affect database field and not Java or minilang.
    

I'm not sure about the WorkEffort.description change... perhaps so, but I don't like it. What would be the reason for breaking the pattern elsewhere here... or in other words how is the WorkEffort description different than other descriptions in the system?

For the CustRequest.description I'd say that this is definitely a bad idea. The intent of the CustRequest design is that the details do _not_ go in the CustRequest entry... they go in the CustRequestItem, specifically in the "story" field which is a very-long.

-David

 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev


  

 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

[David E. Jones]

Si Chen wrote:
> Hi David,
>
> 1.   I don't love "floating-point" either.  Should make a new fieldtype
> now for say DECIMAL(18,10).  Or we can just use floating-point for now
> and change it later.

The main reason I don't like this sort of data type for currency data is having too much precision. For final calculated values, like an order total or in most cases an item price, you don't want anything beyond 2 decimal places because it's not possible (legally if I understand it right) to transact in values smaller than this, so having more information is a liability.

As far as floating point versus fixed point for these more precise values: there are some issues with floating point numbers because of the way they are represented in binary, but I don't think we'll run into those in this scale of precision, especially if we do proper rounding before calculations and such.

> 2.  Is there a field for recording detailed information about a
> WorkEffort, similar to CustRequestItem?

This is a good question... To determine the best way to handle this I _still_ need to know what it is we are trying to handle here. I was trying to get to that with the question about how this description would be different from others, but perhaps a better question is what exactly are you trying to store?

There is a noteId on the WorkEffort entity for storing notes related to the WorkEffort. I'm not sure why there is just a single noteId... it would be better to have a set of notes associated with it and there is an entity for that ("WorkEffortNote") so I don't know why a noteId field even exists.

Whatever the case, this is probably a good place to put notes and details about a WorkEffort.

You should also note that WorkEfforts are meant to be hierarchical and attached to other things in the system, and that is where the detail usually lives.

I'm 90% guessing here, but if you are working on a work management system or something then the details for a "task" would usually be in the CustRequest or Requirement associated with the WorkEffort.

Out of curiosity: could you share what sort of effort this is part of?

In general, for you and everyone: _please_ do more data model review before proposing changes, and when proposing changes _please_ be specific about what the fields or entities are intended to be used for. I don't mind doing free analysis to help keep the data model and other things in OFBiz as clean as possible, but if I have to guess at the details and intent it is hard to do anything effective with it.

-David

 

> 3.  Ok, I won't make it for CustRequest.  Thanks for pointing that out.
>
> Si
>
> David E. Jones wrote:
>> Si Chen wrote:
>>  
>>> Hi everybody -
>>>
>>> Just wanted to confirm if it'd be OK to change the following field types:
>>>
>>> InventoryItem.unitCost and CostCompnent.cost to "floating-point":
>>> because these fields may be calculated, and we need maximum precision
>>> stored in database.  Should not affect Java or minilang code.
>>>    
>>
>> These might be okay, but I want to note for everyone that I don't like using floating-point in general for currency related values. These aren't really "final" values so are a very different case, and this might be the best way to go.
>>
>>  
>>> WorkEffort.description and CustRequest.description to "very-long":
>>> because they're used for descriptive entries, 255 chars is sometimes not
>>> enough.  Again, should only affect database field and not Java or minilang.
>>>    
>>
>> I'm not sure about the WorkEffort.description change... perhaps so, but I don't like it. What would be the reason for breaking the pattern elsewhere here... or in other words how is the WorkEffort description different than other descriptions in the system?
>>
>> For the CustRequest.description I'd say that this is definitely a bad idea. The intent of the CustRequest design is that the details do _not_ go in the CustRequest entry... they go in the CustRequestItem, specifically in the "story" field which is a very-long.
>>
>> -David
>>

 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

[Si Chen-2]

Hi David,

David E. Jones wrote:

Si Chen wrote:
  

Hi David,

1.   I don't love "floating-point" either.  Should make a new fieldtype 
now for say DECIMAL(18,10).  Or we can just use floating-point for now 
and change it later.
    

The main reason I don't like this sort of data type for currency data is having too much precision. For final calculated values, like an order total or in most cases an item price, you don't want anything beyond 2 decimal places because it's not possible (legally if I understand it right) to transact in values smaller than this, so having more information is a liability.

As far as floating point versus fixed point for these more precise values: there are some issues with floating point numbers because of the way they are represented in binary, but I don't think we'll run into those in this scale of precision, especially if we do proper rounding before calculations and such.

  

I agree currency-amount is fine for final values.  For intermediate calculated values, though, like the averaged out unit cost, we do need more precision, but it sounds like floating-point will do for now.

2.  Is there a field for recording detailed information about a 
WorkEffort, similar to CustRequestItem?
    

This is a good question... To determine the best way to handle this I _still_ need to know what it is we are trying to handle here. I was trying to get to that with the question about how this description would be different from others, but perhaps a better question is what exactly are you trying to store?

There is a noteId on the WorkEffort entity for storing notes related to the WorkEffort. I'm not sure why there is just a single noteId... it would be better to have a set of notes associated with it and there is an entity for that ("WorkEffortNote") so I don't know why a noteId field even exists.
  

I agree.  I saw it once and thought it was strange too.  Should we take it out?

Whatever the case, this is probably a good place to put notes and details about a WorkEffort.

You should also note that WorkEfforts are meant to be hierarchical and attached to other things in the system, and that is where the detail usually lives.

I'm 90% guessing here, but if you are working on a work management system or something then the details for a "task" would usually be in the CustRequest or Requirement associated with the WorkEffort.

Out of curiosity: could you share what sort of effort this is part of?

  

Well, it was a bug which came up from our new CRM, but would be the same if someone used Work Effort.  Basically, it came from someone wanting to type in very long ("very-long"?) descriptions of their problems.  Nothing more sophisticated than that.  So if somebody just wants to type in very lengthy explanations, I thought it *might* make sense just to change these fields, rather than adding CustRequestItem or Notes, which are different concepts in my mind--namely, itemization of the request or notes about it.

In general, for you and everyone: _please_ do more data model review before proposing changes, and when proposing changes _please_ be specific about what the fields or entities are intended to be used for. I don't mind doing free analysis to help keep the data model and other things in OFBiz as clean as possible, but if I have to guess at the details and intent it is hard to do anything effective with it.

  

Certainly, I'll do my best.

-David

 
  

3.  Ok, I won't make it for CustRequest.  Thanks for pointing that out.

Si

David E. Jones wrote:
    

Si Chen wrote:
  
      

Hi everybody -

Just wanted to confirm if it'd be OK to change the following field types:

InventoryItem.unitCost and CostCompnent.cost to "floating-point": 
because these fields may be calculated, and we need maximum precision 
stored in database.  Should not affect Java or minilang code.
    
        

These might be okay, but I want to note for everyone that I don't like using floating-point in general for currency related values. These aren't really "final" values so are a very different case, and this might be the best way to go.

  
      

WorkEffort.description and CustRequest.description to "very-long": 
because they're used for descriptive entries, 255 chars is sometimes not 
enough.  Again, should only affect database field and not Java or minilang.
    
        

I'm not sure about the WorkEffort.description change... perhaps so, but I don't like it. What would be the reason for breaking the pattern elsewhere here... or in other words how is the WorkEffort description different than other descriptions in the system?

For the CustRequest.description I'd say that this is definitely a bad idea. The intent of the CustRequest design is that the details do _not_ go in the CustRequest entry... they go in the CustRequestItem, specifically in the "story" field which is a very-long.

-David

      

 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev


  

 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev