Odd Error

["skip@theDevers" <sk...@thedevers.org>]

I am getting lots of warnings like this:

2007-10-08 20:52:03,096 (AWT-EventQueue-0) [
GenericEntity.java:389:WARN ] In entity field
[GlAccountHistory.postedDebits] set the value passed in
[java.math.BigDecimal] is not compatible with the Java type of the field
[Double]

I am pretty sure I can fix this, but do I need to?

Skip

Re: Odd Error

[David E Jones <jo...@hotwaxmedia.com>]

No, don't submit anything. That is an expected message. This is part  
of the larger effort to convert all Double based math to be  
BigDecimal based.

-David


On Oct 8, 2007, at 10:50 PM, skip@theDevers wrote:

> So should I fix this and post a patch?  Also, looks like a cast to  
> a double
> and not a long, and I don't think BigDecimal is castable to  
> Double.  My
> intent was to go into the entity engine code and check for  
> BigDecimal return
> type and automatically convert it to a Double if that was what is  
> required
> by the db.
>
> Also, note that this was a warning, not an error.
>
> -----Original Message-----
> From: BJ Freeman [mailto:bjfree@free-man.net]
> Sent: Monday, October 08, 2007 9:05 PM
> To: user@ofbiz.apache.org
> Subject: Re: Odd Error
>
>
> got this on compile from recent 4.0 release
> I just added a (long) cast and it fixed it.
> have not gone back into to the commit logs to find out why.
>
> skip@theDevers sent the following on 10/8/2007 9:00 PM:
>> I am getting lots of warnings like this:
>>
>> 2007-10-08 20:52:03,096 (AWT-EventQueue-0) [
>> GenericEntity.java:389:WARN ] In entity field
>> [GlAccountHistory.postedDebits] set the value passed in
>> [java.math.BigDecimal] is not compatible with the Java type of the  
>> field
>> [Double]
>>
>> I am pretty sure I can fix this, but do I need to?
>>
>> Skip
>>
>>
>>
>>
>

RE: Odd Error

["skip@theDevers" <sk...@thedevers.org>]

Jonathon

For the A/R aging, there is no need to delete the table at the end, you
could just delete all the records before you start over the next month.
(Although if you wanted to split the work up to an unknown number of people,
you would need some temporary files).

The purchacing is somewhat different (in the current use case) because the
number of people assigned to purchasing this run is unknown until runtime.

I could just create like 10 tables, and use the first x, but this seems
pretty crude when the simple ability to dynamically create and destroy
tables would make it easy and less work on the underlying db.

So, is there really no way to dynamically create and delete tables?


BJ sez there are some samples in the Manufacturing module.  Is this already
done there?  (I havent looked at it because I don't have a need for
Manufacturing atm).



Skip

-----Original Message-----
From: Jonathon -- Improov [mailto:jonw@improov.com]
Sent: Thursday, October 11, 2007 4:38 AM
To: user@ofbiz.apache.org
Subject: Re: Odd Error


I don't think Dynamic Views can help here. The "purchasing recommendation"
is generated once, and
is then presented again and again to the end-user. It is not generated every
time the end-user
needs to see it.

How about creating a permanent table for both "purchasing recommendation"
and aging AR? Why does
it have to be a temporary table?

When talking about "temporary data", I think it's still alright to store
them in permanent tables.
Login history is temporary enough. So is Visit(s). And others. I even stored
"temporary passwords"
in permanent tables, and just delete those passwords that are superseded by
the creation of
"permanent passwords".

Jonathon

vijay Si wrote:
> I think Dynamic Views could help, but again u need to test performance
>
> On 10/11/07, skip@theDevers <sk...@thedevers.org> wrote:
>> Hi guys
>>
>> I have the need to develop a purchasing application that scans the last
>> months sales, compares estimated shipping times and onhand quantities to
>> generate purchacing recommendations (actually a good deal more
complicated
>> than this, but thats the gist).  The resulting file is presented to the
>> user
>> who examines it over a few days and takes action on it.  Then, it gets
>> deleted.  There is an undetermined number of files to be created
>> (depending
>> on how many people are doing purchasing at that time) all with the same
>> structure.
>>
>> This means that I'll have to create a few temporary tables to hold the
>> data
>> and then delete them after the work is finished.
>>
>> I have a similiar need for aging Accounts Receivable.
>>
>> What is the recommended way of creating temporary tables and then
deleting
>> them when they are no longer needed?  I know how to do this in SQL, just
>> not
>> in Ofbiz.
>>
>> Skip
>>
>>
>
>
> ------------------------------------------------------------------------
>
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.5.488 / Virus Database: 269.14.7/1062 - Release Date:
10/10/2007 5:11 PM

Re: Odd Error

[Jonathon -- Improov <jo...@improov.com>]

I don't think Dynamic Views can help here. The "purchasing recommendation" is generated once, and 
is then presented again and again to the end-user. It is not generated every time the end-user 
needs to see it.

How about creating a permanent table for both "purchasing recommendation" and aging AR? Why does 
it have to be a temporary table?

When talking about "temporary data", I think it's still alright to store them in permanent tables. 
Login history is temporary enough. So is Visit(s). And others. I even stored "temporary passwords" 
in permanent tables, and just delete those passwords that are superseded by the creation of 
"permanent passwords".

Jonathon

vijay Si wrote:
> I think Dynamic Views could help, but again u need to test performance
> 
> On 10/11/07, skip@theDevers <sk...@thedevers.org> wrote:
>> Hi guys
>>
>> I have the need to develop a purchasing application that scans the last
>> months sales, compares estimated shipping times and onhand quantities to
>> generate purchacing recommendations (actually a good deal more complicated
>> than this, but thats the gist).  The resulting file is presented to the
>> user
>> who examines it over a few days and takes action on it.  Then, it gets
>> deleted.  There is an undetermined number of files to be created
>> (depending
>> on how many people are doing purchasing at that time) all with the same
>> structure.
>>
>> This means that I'll have to create a few temporary tables to hold the
>> data
>> and then delete them after the work is finished.
>>
>> I have a similiar need for aging Accounts Receivable.
>>
>> What is the recommended way of creating temporary tables and then deleting
>> them when they are no longer needed?  I know how to do this in SQL, just
>> not
>> in Ofbiz.
>>
>> Skip
>>
>>
> 
> 
> ------------------------------------------------------------------------
> 
> No virus found in this incoming message.
> Checked by AVG Free Edition. 
> Version: 7.5.488 / Virus Database: 269.14.7/1062 - Release Date: 10/10/2007 5:11 PM

Re: Odd Error

[vijay Si <st...@gmail.com>]

I think Dynamic Views could help, but again u need to test performance

On 10/11/07, skip@theDevers <sk...@thedevers.org> wrote:
>
> Hi guys
>
> I have the need to develop a purchasing application that scans the last
> months sales, compares estimated shipping times and onhand quantities to
> generate purchacing recommendations (actually a good deal more complicated
> than this, but thats the gist).  The resulting file is presented to the
> user
> who examines it over a few days and takes action on it.  Then, it gets
> deleted.  There is an undetermined number of files to be created
> (depending
> on how many people are doing purchasing at that time) all with the same
> structure.
>
> This means that I'll have to create a few temporary tables to hold the
> data
> and then delete them after the work is finished.
>
> I have a similiar need for aging Accounts Receivable.
>
> What is the recommended way of creating temporary tables and then deleting
> them when they are no longer needed?  I know how to do this in SQL, just
> not
> in Ofbiz.
>
> Skip
>
>

Re:MRP was Odd Error

[BJ Freeman <bj...@free-man.net>]

have you looked thru the manufacturing module?
you can always define and entity for your data
then clear it out when finished.

skip@theDevers sent the following on 10/10/2007 8:32 PM:
> Hi guys
> 
> I have the need to develop a purchasing application that scans the last
> months sales, compares estimated shipping times and onhand quantities to
> generate purchacing recommendations (actually a good deal more complicated
> than this, but thats the gist).  The resulting file is presented to the user
> who examines it over a few days and takes action on it.  Then, it gets
> deleted.  There is an undetermined number of files to be created (depending
> on how many people are doing purchasing at that time) all with the same
> structure.
> 
> This means that I'll have to create a few temporary tables to hold the data
> and then delete them after the work is finished.
> 
> I have a similiar need for aging Accounts Receivable.
> 
> What is the recommended way of creating temporary tables and then deleting
> them when they are no longer needed?  I know how to do this in SQL, just not
> in Ofbiz.
> 
> Skip
> 
> 
> 
> 

RE: Odd Error

["skip@theDevers" <sk...@thedevers.org>]

Hi guys

I have the need to develop a purchasing application that scans the last
months sales, compares estimated shipping times and onhand quantities to
generate purchacing recommendations (actually a good deal more complicated
than this, but thats the gist).  The resulting file is presented to the user
who examines it over a few days and takes action on it.  Then, it gets
deleted.  There is an undetermined number of files to be created (depending
on how many people are doing purchasing at that time) all with the same
structure.

This means that I'll have to create a few temporary tables to hold the data
and then delete them after the work is finished.

I have a similiar need for aging Accounts Receivable.

What is the recommended way of creating temporary tables and then deleting
them when they are no longer needed?  I know how to do this in SQL, just not
in Ofbiz.

Skip

Re: Odd Error

[BJ Freeman <bj...@free-man.net>]

believe there is a jira on this issue
https://issues.apache.org/jira/browse/OFBIZ-1314
is the last one.

skip@theDevers sent the following on 10/8/2007 9:50 PM:
> So should I fix this and post a patch?  Also, looks like a cast to a double
> and not a long, and I don't think BigDecimal is castable to Double.  My
> intent was to go into the entity engine code and check for BigDecimal return
> type and automatically convert it to a Double if that was what is required
> by the db.
> 
> Also, note that this was a warning, not an error.
> 
> -----Original Message-----
> From: BJ Freeman [mailto:bjfree@free-man.net]
> Sent: Monday, October 08, 2007 9:05 PM
> To: user@ofbiz.apache.org
> Subject: Re: Odd Error
> 
> 
> got this on compile from recent 4.0 release
> I just added a (long) cast and it fixed it.
> have not gone back into to the commit logs to find out why.
> 
> skip@theDevers sent the following on 10/8/2007 9:00 PM:
>> I am getting lots of warnings like this:
>>
>> 2007-10-08 20:52:03,096 (AWT-EventQueue-0) [
>> GenericEntity.java:389:WARN ] In entity field
>> [GlAccountHistory.postedDebits] set the value passed in
>> [java.math.BigDecimal] is not compatible with the Java type of the field
>> [Double]
>>
>> I am pretty sure I can fix this, but do I need to?
>>
>> Skip
>>
>>
>>
>>
> 
> 
> 
> 

RE: Odd Error

["skip@theDevers" <sk...@thedevers.org>]

So should I fix this and post a patch?  Also, looks like a cast to a double
and not a long, and I don't think BigDecimal is castable to Double.  My
intent was to go into the entity engine code and check for BigDecimal return
type and automatically convert it to a Double if that was what is required
by the db.

Also, note that this was a warning, not an error.

-----Original Message-----
From: BJ Freeman [mailto:bjfree@free-man.net]
Sent: Monday, October 08, 2007 9:05 PM
To: user@ofbiz.apache.org
Subject: Re: Odd Error


got this on compile from recent 4.0 release
I just added a (long) cast and it fixed it.
have not gone back into to the commit logs to find out why.

skip@theDevers sent the following on 10/8/2007 9:00 PM:
> I am getting lots of warnings like this:
>
> 2007-10-08 20:52:03,096 (AWT-EventQueue-0) [
> GenericEntity.java:389:WARN ] In entity field
> [GlAccountHistory.postedDebits] set the value passed in
> [java.math.BigDecimal] is not compatible with the Java type of the field
> [Double]
>
> I am pretty sure I can fix this, but do I need to?
>
> Skip
>
>
>
>

Re: Odd Error

[BJ Freeman <bj...@free-man.net>]

got this on compile from recent 4.0 release
I just added a (long) cast and it fixed it.
have not gone back into to the commit logs to find out why.

skip@theDevers sent the following on 10/8/2007 9:00 PM:
> I am getting lots of warnings like this:
> 
> 2007-10-08 20:52:03,096 (AWT-EventQueue-0) [
> GenericEntity.java:389:WARN ] In entity field
> [GlAccountHistory.postedDebits] set the value passed in
> [java.math.BigDecimal] is not compatible with the Java type of the field
> [Double]
> 
> I am pretty sure I can fix this, but do I need to?
> 
> Skip
> 
> 
> 
>