You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ofbiz.apache.org by "David E. Jones" <jo...@undersunconsulting.com> on 2007/02/03 08:49:25 UTC
Re: svn commit: r502824 - /ofbiz/trunk/applications/product/script/org/ofbiz/product/inventory/InventoryReserveServices.xml
Hold on a minute there.... did you actually test and find this to be
a problem? The +/- notation is an entity engine ONLY thing and should
never make it to the database.
This patch should be reverted and if +/- are making it to the
database instead of being replaced with an ASC/DESC by the entity
engine then THAT bug should be fixed.
This is a slippery slope and we should backup to the top before it
gets going...
-David
On Feb 2, 2007, at 6:16 PM, sichen@apache.org wrote:
> Author: sichen
> Date: Fri Feb 2 17:16:36 2007
> New Revision: 502824
>
> URL: http://svn.apache.org/viewvc?view=rev&rev=502824
> Log:
> Fix a pretty significant bug with sequence of inventory item
> reservations for orders: FIFO and LIFO were reversed (I checked
> this) and the +/- notation does not work well with PostgreSQL
>
> Modified:
> ofbiz/trunk/applications/product/script/org/ofbiz/product/
> inventory/InventoryReserveServices.xml
>
> Modified: ofbiz/trunk/applications/product/script/org/ofbiz/product/
> inventory/InventoryReserveServices.xml
> URL: http://svn.apache.org/viewvc/ofbiz/trunk/applications/product/
> script/org/ofbiz/product/inventory/InventoryReserveServices.xml?
> view=diff&rev=502824&r1=502823&r2=502824
> ======================================================================
> ========
> --- ofbiz/trunk/applications/product/script/org/ofbiz/product/
> inventory/InventoryReserveServices.xml (original)
> +++ ofbiz/trunk/applications/product/script/org/ofbiz/product/
> inventory/InventoryReserveServices.xml Fri Feb 2 17:16:36 2007
> @@ -42,23 +42,26 @@
> <entity-one entity-name="OrderHeader" value-
> name="orderHeader"/>
>
> <!-- before we do the find, put together the orderBy list
> based on which reserveOrderEnumId is specified -->
> + <!-- FIFO=first in first out, so it should be order by
> ASCending receive or expire date
> + LIFO=last in first out, so it means order by
> DESCending receive or expire date
> + -->
> <if-compare value="INVRO_GUNIT_COST" operator="equals"
> field-name="reserveOrderEnumId" map-name="parameters">
> - <set value="-unitCost" field="orderByString"/>
> + <set value="unitCost DESC" field="orderByString"/>
> <else>
> <if-compare value="INVRO_LUNIT_COST" operator="equals"
> field-name="reserveOrderEnumId" map-name="parameters">
> - <set value="+unitCost" field="orderByString"/>
> + <set value="unitCost ASC" field="orderByString"/>
> <else>
> <if-compare value="INVRO_FIFO_EXP"
> operator="equals" field-name="reserveOrderEnumId" map-
> name="parameters">
> - <set value="+expireDate" field="orderByString"/>
> + <set value="expireDate ASC"
> field="orderByString"/>
> <else>
> <if-compare value="INVRO_LIFO_EXP"
> operator="equals" field-name="reserveOrderEnumId" map-
> name="parameters">
> - <set value="-expireDate"
> field="orderByString"/>
> + <set value="expireDate DESC"
> field="orderByString"/>
> <else>
> <if-compare value="INVRO_LIFO_REC"
> operator="equals" field-name="reserveOrderEnumId" map-
> name="parameters">
> - <set value="+datetimeReceived"
> field="orderByString"/>
> + <set value="datetimeReceived DESC"
> field="orderByString"/>
> <else>
> <!-- the default reserveOrderEnumId is
> INVRO_FIFO_REC, ie FIFO based on date received -->
> - <set value="-datetimeReceived"
> field="orderByString"/>
> + <set value="datetimeReceived ASC"
> field="orderByString"/>
> <set value="INVRO_FIFO_REC"
> field="parameters.reserveOrderEnumId"/>
> </else>
> </if-compare>
>
>
Re: svn commit: r502824 - /ofbiz/trunk/applications/product/script/org/ofbiz/product/inventory/InventoryReserveServices.xml
Posted by "David E. Jones" <jo...@hotwaxmedia.com>.
Why change it then? Why put the effort into it, and then require
corresponding review effort?
Why comment "the +/- notation does not work well with PostgreSQL"?
Either way I don't care a lot, as long as it's clear what is being
fixed and what is just being changed because "I like my way better".
-David
On Feb 3, 2007, at 2:51 AM, Leon Torres wrote:
> Hi David,
>
> I was involved in fixing this issue. There was a genuine bug where
> the inventory reservation with FIFO method was ordered the wrong
> way, causing it to behave like LIFO. This commit fixes the issue
> by reversing the order for the FIFO case so it works correctly.
>
> So unless you want to break an important fix, it would be a bad
> idea to revert this.
>
> The ASC/DESC thing is just a clarification and a preference that
> was made in addition to the bug fix. This is *not* just a change
> of syntax commit. Furthermore, there is *no* bug with +- notation.
>
> We prefer to use ASC/DESC because it makes it clearer what's going
> on in this code, and we feel that the +- syntax is more ambiguous
> and most likely led to the incorrect implementation of FIFO in the
> first place.
>
> - Leon
>
>
>
> David E. Jones wrote:
>> Hold on a minute there.... did you actually test and find this to
>> be a problem? The +/- notation is an entity engine ONLY thing and
>> should never make it to the database.
>> This patch should be reverted and if +/- are making it to the
>> database instead of being replaced with an ASC/DESC by the entity
>> engine then THAT bug should be fixed.
>> This is a slippery slope and we should backup to the top before it
>> gets going...
>> -David
>> On Feb 2, 2007, at 6:16 PM, sichen@apache.org wrote:
>>> Author: sichen
>>> Date: Fri Feb 2 17:16:36 2007
>>> New Revision: 502824
>>>
>>> URL: http://svn.apache.org/viewvc?view=rev&rev=502824
>>> Log:
>>> Fix a pretty significant bug with sequence of inventory item
>>> reservations for orders: FIFO and LIFO were reversed (I checked
>>> this) and the +/- notation does not work well with PostgreSQL
>>>
>>> Modified:
>>> ofbiz/trunk/applications/product/script/org/ofbiz/product/
>>> inventory/InventoryReserveServices.xml
>>>
>>> Modified: ofbiz/trunk/applications/product/script/org/ofbiz/
>>> product/inventory/InventoryReserveServices.xml
>>> URL: http://svn.apache.org/viewvc/ofbiz/trunk/applications/
>>> product/script/org/ofbiz/product/inventory/
>>> InventoryReserveServices.xml?
>>> view=diff&rev=502824&r1=502823&r2=502824
>>> ====================================================================
>>> ==========
>>> --- ofbiz/trunk/applications/product/script/org/ofbiz/product/
>>> inventory/InventoryReserveServices.xml (original)
>>> +++ ofbiz/trunk/applications/product/script/org/ofbiz/product/
>>> inventory/InventoryReserveServices.xml Fri Feb 2 17:16:36 2007
>>> @@ -42,23 +42,26 @@
>>> <entity-one entity-name="OrderHeader" value-
>>> name="orderHeader"/>
>>>
>>> <!-- before we do the find, put together the orderBy
>>> list based on which reserveOrderEnumId is specified -->
>>> + <!-- FIFO=first in first out, so it should be order by
>>> ASCending receive or expire date
>>> + LIFO=last in first out, so it means order by
>>> DESCending receive or expire date
>>> + -->
>>> <if-compare value="INVRO_GUNIT_COST" operator="equals"
>>> field-name="reserveOrderEnumId" map-name="parameters">
>>> - <set value="-unitCost" field="orderByString"/>
>>> + <set value="unitCost DESC" field="orderByString"/>
>>> <else>
>>> <if-compare value="INVRO_LUNIT_COST"
>>> operator="equals" field-name="reserveOrderEnumId" map-
>>> name="parameters">
>>> - <set value="+unitCost" field="orderByString"/>
>>> + <set value="unitCost ASC" field="orderByString"/>
>>> <else>
>>> <if-compare value="INVRO_FIFO_EXP"
>>> operator="equals" field-name="reserveOrderEnumId" map-
>>> name="parameters">
>>> - <set value="+expireDate"
>>> field="orderByString"/>
>>> + <set value="expireDate ASC"
>>> field="orderByString"/>
>>> <else>
>>> <if-compare value="INVRO_LIFO_EXP"
>>> operator="equals" field-name="reserveOrderEnumId" map-
>>> name="parameters">
>>> - <set value="-expireDate"
>>> field="orderByString"/>
>>> + <set value="expireDate DESC"
>>> field="orderByString"/>
>>> <else>
>>> <if-compare value="INVRO_LIFO_REC"
>>> operator="equals" field-name="reserveOrderEnumId" map-
>>> name="parameters">
>>> - <set value="+datetimeReceived"
>>> field="orderByString"/>
>>> + <set value="datetimeReceived DESC"
>>> field="orderByString"/>
>>> <else>
>>> <!-- the default reserveOrderEnumId
>>> is INVRO_FIFO_REC, ie FIFO based on date received -->
>>> - <set value="-datetimeReceived"
>>> field="orderByString"/>
>>> + <set value="datetimeReceived ASC"
>>> field="orderByString"/>
>>> <set value="INVRO_FIFO_REC"
>>> field="parameters.reserveOrderEnumId"/>
>>> </else>
>>> </if-compare>
>>>
>>>
Re: svn commit: r502824 - /ofbiz/trunk/applications/product/script/org/ofbiz/product/inventory/InventoryReserveServices.xml
Posted by Leon Torres <le...@oss.minimetria.com>.
Hi David,
I was involved in fixing this issue. There was a genuine bug where the
inventory reservation with FIFO method was ordered the wrong way, causing it to
behave like LIFO. This commit fixes the issue by reversing the order for the
FIFO case so it works correctly.
So unless you want to break an important fix, it would be a bad idea to revert this.
The ASC/DESC thing is just a clarification and a preference that was made in
addition to the bug fix. This is *not* just a change of syntax commit.
Furthermore, there is *no* bug with +- notation.
We prefer to use ASC/DESC because it makes it clearer what's going on in this
code, and we feel that the +- syntax is more ambiguous and most likely led to
the incorrect implementation of FIFO in the first place.
- Leon
David E. Jones wrote:
>
> Hold on a minute there.... did you actually test and find this to be a
> problem? The +/- notation is an entity engine ONLY thing and should
> never make it to the database.
>
> This patch should be reverted and if +/- are making it to the database
> instead of being replaced with an ASC/DESC by the entity engine then
> THAT bug should be fixed.
>
> This is a slippery slope and we should backup to the top before it gets
> going...
>
> -David
>
>
> On Feb 2, 2007, at 6:16 PM, sichen@apache.org wrote:
>
>> Author: sichen
>> Date: Fri Feb 2 17:16:36 2007
>> New Revision: 502824
>>
>> URL: http://svn.apache.org/viewvc?view=rev&rev=502824
>> Log:
>> Fix a pretty significant bug with sequence of inventory item
>> reservations for orders: FIFO and LIFO were reversed (I checked this)
>> and the +/- notation does not work well with PostgreSQL
>>
>> Modified:
>>
>> ofbiz/trunk/applications/product/script/org/ofbiz/product/inventory/InventoryReserveServices.xml
>>
>>
>> Modified:
>> ofbiz/trunk/applications/product/script/org/ofbiz/product/inventory/InventoryReserveServices.xml
>>
>> URL:
>> http://svn.apache.org/viewvc/ofbiz/trunk/applications/product/script/org/ofbiz/product/inventory/InventoryReserveServices.xml?view=diff&rev=502824&r1=502823&r2=502824
>>
>> ==============================================================================
>>
>> ---
>> ofbiz/trunk/applications/product/script/org/ofbiz/product/inventory/InventoryReserveServices.xml
>> (original)
>> +++
>> ofbiz/trunk/applications/product/script/org/ofbiz/product/inventory/InventoryReserveServices.xml
>> Fri Feb 2 17:16:36 2007
>> @@ -42,23 +42,26 @@
>> <entity-one entity-name="OrderHeader" value-name="orderHeader"/>
>>
>> <!-- before we do the find, put together the orderBy list
>> based on which reserveOrderEnumId is specified -->
>> + <!-- FIFO=first in first out, so it should be order by
>> ASCending receive or expire date
>> + LIFO=last in first out, so it means order by DESCending
>> receive or expire date
>> + -->
>> <if-compare value="INVRO_GUNIT_COST" operator="equals"
>> field-name="reserveOrderEnumId" map-name="parameters">
>> - <set value="-unitCost" field="orderByString"/>
>> + <set value="unitCost DESC" field="orderByString"/>
>> <else>
>> <if-compare value="INVRO_LUNIT_COST" operator="equals"
>> field-name="reserveOrderEnumId" map-name="parameters">
>> - <set value="+unitCost" field="orderByString"/>
>> + <set value="unitCost ASC" field="orderByString"/>
>> <else>
>> <if-compare value="INVRO_FIFO_EXP" operator="equals"
>> field-name="reserveOrderEnumId" map-name="parameters">
>> - <set value="+expireDate" field="orderByString"/>
>> + <set value="expireDate ASC" field="orderByString"/>
>> <else>
>> <if-compare value="INVRO_LIFO_EXP"
>> operator="equals" field-name="reserveOrderEnumId" map-name="parameters">
>> - <set value="-expireDate" field="orderByString"/>
>> + <set value="expireDate DESC"
>> field="orderByString"/>
>> <else>
>> <if-compare value="INVRO_LIFO_REC"
>> operator="equals" field-name="reserveOrderEnumId" map-name="parameters">
>> - <set value="+datetimeReceived"
>> field="orderByString"/>
>> + <set value="datetimeReceived DESC"
>> field="orderByString"/>
>> <else>
>> <!-- the default reserveOrderEnumId is
>> INVRO_FIFO_REC, ie FIFO based on date received -->
>> - <set value="-datetimeReceived"
>> field="orderByString"/>
>> + <set value="datetimeReceived ASC"
>> field="orderByString"/>
>> <set value="INVRO_FIFO_REC"
>> field="parameters.reserveOrderEnumId"/>
>> </else>
>> </if-compare>
>>
>>
>
Re: svn commit: r502824 - /ofbiz/trunk/applications/product/script/org/ofbiz/product/inventory/InventoryReserveServices.xml
Posted by Jonathon -- Improov <jo...@improov.com>.
Tim, Jacopo,
Well, since you put this in the open, I guess I might as well re-examine my previous posts.
In Jacopo's case, it all did start out with me appreciating his help. In one of my first posts, I
made the mistake of recalling that it was Jacopo who corrected me on the "please use absolute path
in your diff/patches". Jacques informed us it was actually him. Incidentally, you'll note that I
always use myself and my own mistakes to illustrate "how things should be done". That particular
post was in a thread where David was suggesting a pre-commit review or lamenting the lack thereof.
Anyway, you'll see the same styles everywhere. Any to-the-point criticisms are first directed at
myself, sometimes even almost deviating from the truth in cases where I wasn't quite able to find
an example that qualifies myself as a target for said criticisms. At times, I may even have
stretched the truth about myself in order to "smooth things out", and could've been accused of
hypocrisy. For eg, I do have the tendency to admit to wrongdoing to some extent in order to "let
the dust settle". I wouldn't state the exact audience that witnessed this style (and the responses
to it) on this ML, but I can tell you that you can consider my tact universally acknowledged (and
in some cases even disapproved of, because the tact gave way to ill reason and bordered on letting
dishonesty take the final note.) Yes, my boss or bosses (future/potential ones) are in that
audience. Part of that audience also includes Singaporean companies deciding whether they want to
go with OFBiz.
(And for the record, to be clearly honest for a change, things are not looking good at all. Yes,
they're watching every message I type, so you should know I'm your biggest proponent here. Stuck
in a difficult in-between place.)
Back to Jacopo's case. One of the first "good rubs" with Jacopo was with the Product Variant BOMs
help from Jacopo. In fact, about the biggest reason my current boss is still with OFBiz is because
of his work in Manufacturing module. As I mentioned in a post to David, we're watching Jacopo; I
recommended him to cover for me in tech support once my project is done. After all, my boss is in
manufacturing and Jacopo has done a lot there. Despite his recent display (we're still comparing
with his past posts way back for a more holistic assessment), I still think he's the right candidate.
I'm not going to ask the ML (or anybody, for that matter) to admonish him for his behavior. He's
done a lot for OFBiz, and I'd honestly say he should take his Manufacturing module away with him
if we're to ask him to go away. I don't want him to go away. I don't want to be put in that
difficult position, so that's why I wouldn't want David in that position either. Well there I go
again, that same style. :) If Jacopo goes, OFBiz will not hold enough value for me and my bosses.
As for really rubbing some people the wrong way, I guess it has a lot to do with the fact that
I've weaned myself (and my bosses and future bosses) from dependence on ML tech support (yes, it
was officially deemed a non-support channel some weeks back). And possibly even more because I
unwittingly "damaged" the business model for some people here. I honestly didn't know at first the
technical references for OFBiz are only sold commercially. Upon realizing it, I had then consulted
David privately to ask if there's anything I can do (eg NOT publish my altruistic
yet-to-be-written Engineer's Manual) if it meant righting an imbalance in "give-and-take"
situation between OFBiz and users. David said it's Undersun that's profiting from those
commercially sold tech references, not OFBiz.
(I hope the dev list doesn't have paid customers, because some did complain about the tech
references sold. I have never seen those references, and can't comment. Would've wanted this post
to be private, but maybe I should really be perfectly honest for a change. Bosses would fry me if
they bought those references owing to my comments or the lack thereof, so I have to say I'm
neither arguing against nor for those references.)
Please understand that I had no option to avoid taking apart OFBiz and weaning my bosses from
reliance on a "difficult channel" for tech support. It was about the only way I could keep them
from chucking OFBiz in the trash. And maybe I should be honest (but I thought I'd mentioned this
several times) about my occupation; I'm a LEGAL reverse-engineer by trade (not just Java
compiled/source codes). If there's an implicit ban againt reverse-engineers in ML, please let me
know and I'll gladly oblige. This isn't my grandfather's ML. (There, same style again.)
I will certainly take your suggestions seriously, and heed your call for us to "come
[cooperate/play] together". However, I do hope the ML can appreciate that I'm caught in a
difficult in-between position, and my comments on the ML cannot deviate too far from "honest
business sense". I'd have thought my arguments for OFBiz are all the more potent precisely because
of my stark objectivity. And that appears to be the case (for now), since my bosses haven't turned
away from OFBiz yet.
I hope that this thread being on the dev list will mean it will stop here. I wouldn't want another
"baggin on OFBiz" session (you know my stakes in OFBiz). If it does spark a rowdy discussion, I'll
be the first to call for a stop to that.
One important note about the ML. I have noticed it's probably hard for some people to scan through
surrounding contexts (posts related to a post) when responding to a post. Perhaps that's where the
problem is?
I hope we understand each other more from this.
Jonathon
Tim Ruppert wrote:
> Jonathon as an innocent bystander, all I can say is that with every word
> you type you are rubbing people the wrong way. Please just take a
> moment to read thru your posts before hitting send - and think about the
> fact that there are tons of people here from different backgrounds who
> are pushing towards the same goal.
>
> I realize that your intentions are good and that you're working towards
> that same goal, but understand that if you're rubbing everyone the wrong
> way - it might not be them, but how you're choosing to phrase your
> questions, comments and concerns.
>
> All I ask is that you think about what you're saying and where you
> really want things to go and phrase things accordingly. I'm not saying
> that all responses to your digging have been phrased smoothly - but you
> can only control yourself - so let's all give it a try.
>
> This is not totally relevant, but I believe I wrote this up sometime
> around the last episode people rubbing others the wrong way on the dev
> list
> - http://www.nabble.com/Why's-everybody-baggin'-on-OFBiz-lately-t3081858.html
>
> Anyways, I hope you read this for what it is - a request to come
> together - and you take my suggestions seriously. Thanks for posting
> Jonathon and we look forward to more helpful things out of your in the
> future.
>
> Cheers,
> Tim
> --
> Tim Ruppert
> HotWax Media
> http://www.hotwaxmedia.com
>
> o:801.649.6594
> f:801.649.6595
>
>
> On Feb 7, 2007, at 3:27 AM, Jonathon -- Improov wrote:
>
>> Jacopo,
>>
>> No, I'm not trolling. Are you?
>>
>> If you meant the last concise post to you, it's because I know you're
>> really really busy. Just a sincere effort to cut down on "extras" in
>> my writing to you.
>>
>> If you meant my comment on David's and Si Chen's discussion, like I
>> said, you better re-read for yourself. I'd rather not repeat something
>> so often it seems like I'm rubbing a fact in or something.
>>
>> If you're still miffed for some reason, I'll say sorry again. But I
>> think we both better watch out, and stop this somewhere sometime soon.
>> Or both of us will be accused of messing up!
>>
>> As I said, all posts are cached or read or otherwise recorded or
>> witnessed by others. We should both take a step back and re-read past
>> posts in order to avoid further misunderstanding.
>>
>> My actions are plain for all to see, and so are yours. We should both
>> behave ourselves. Agree? :)
>>
>> Jonathon
>>
>> Jacopo Cappellato wrote:
>>> Jonathon,
>>> are you trolling?
>>> Jacopo
>>> Jonathon -- Improov wrote:
>>>> Er, Jacopo. Maybe I moved your cheese some time, I don't know. If
>>>> so, sorry!
>>>>
>>>> Since you like conciseness, please re-read this thread between David
>>>> and Si Chen.
>>>>
>>>> As for incorrect information, re-read my previous posts.
>>>>
>>>> Jonathon
>>>>
>>>> Jacopo Cappellato wrote:
>>>>> Jonathon -- Improov wrote:
>>>>>> Si Chen,
>>>>>>
>>>>>> I wasn't "saying" anything.
>>>>>
>>>>> I think that this is the problem with many of your (and with those
>>>>> of some new guys that recently are around in these lists) posts,
>>>>> Jonathon: you say nothing with too many words, and this is
>>>>> confusing, especially for new users and, in the dev list, it is
>>>>> annoying because it's difficult to concentrate and discuss on the
>>>>> development of OFBiz.
>>>>> There is no need to comment every post and in general silence is
>>>>> better than incorrect or partially correct information.
>>>>>
>>>>> Jacopo
>>>>>
>>>>>
>>>>>
>>>>>
>>
>
Re: svn commit: r502824 -/ofbiz/trunk/applications/product/script/org/ofbiz/product/inventory/InventoryReserveServices.xml
Posted by Jacopo Cappellato <ti...@sastau.it>.
Jacques,
that's a great comment! You've made me smile, thanks.
Jacopo
Jacques Le Roux wrote:
> Just one word :
>
> Please "-*DON ' T*_ use absolute pathes in your diff/patches but relative to root"
>
> Jacques
>
Re: svn commit: r502824
-/ofbiz/trunk/applications/product/script/org/ofbiz/product/inventory/InventoryReserveServices.xml
Posted by Jacques Le Roux <ja...@les7arts.com>.
Just one word :
Please "-*DON ' T*_ use absolute pathes in your diff/patches but relative to root"
Jacques
----- Original Message -----
From: "Andrew Sykes" <an...@sykesdevelopment.com>
To: <de...@ofbiz.apache.org>
Sent: Thursday, February 08, 2007 12:17 AM
Subject: Re: svn commit: r502824 -/ofbiz/trunk/applications/product/script/org/ofbiz/product/inventory/InventoryReserveServices.xml
> Please please guys, just drop this,
>
> I'm sure none of us who are having to delete all this nonsense really
> care.
>
> - Andrew
>
>
> On Thu, 2007-02-08 at 06:56 +0800, Jonathon -- Improov wrote:
> > Tim, Jacopo,
> >
> > Well, since you put this in the open, I guess I might as well re-examine my previous posts.
> >
> > In Jacopo's case, it all did start out with me appreciating his help. In one of my first posts, I
> > made the mistake of recalling that it was Jacopo who corrected me on the "please use absolute path
> > in your diff/patches". Jacques informed us it was actually him. Incidentally, you'll note that I
> > always use myself and my own mistakes to illustrate "how things should be done". That particular
> > post was in a thread where David was suggesting a pre-commit review or lamenting the lack thereof.
> >
> > Anyway, you'll see the same styles everywhere. Any to-the-point criticisms are first directed at
> > myself, sometimes even almost deviating from the truth in cases where I wasn't quite able to find
> > an example that qualifies myself as a target for said criticisms. At times, I may even have
> > stretched the truth about myself in order to "smooth things out", and could've been accused of
> > hypocrisy. For eg, I do have the tendency to admit to wrongdoing to some extent in order to "let
> > the dust settle". I wouldn't state the exact audience that witnessed this style (and the responses
> > to it) on this ML, but I can tell you that you can consider my tact universally acknowledged (and
> > in some cases even disapproved of, because the tact gave way to ill reason and bordered on letting
> > dishonesty take the final note.) Yes, my boss or bosses (future/potential ones) are in that
> > audience. Part of that audience also includes Singaporean companies deciding whether they want to
> > go with OFBiz.
> >
> > (And for the record, to be clearly honest for a change, things are not looking good at all. Yes,
> > they're watching every message I type, so you should know I'm your biggest proponent here. Stuck
> > in a difficult in-between place.)
> >
> > Back to Jacopo's case. One of the first "good rubs" with Jacopo was with the Product Variant BOMs
> > help from Jacopo. In fact, about the biggest reason my current boss is still with OFBiz is because
> > of his work in Manufacturing module. As I mentioned in a post to David, we're watching Jacopo; I
> > recommended him to cover for me in tech support once my project is done. After all, my boss is in
> > manufacturing and Jacopo has done a lot there. Despite his recent display (we're still comparing
> > with his past posts way back for a more holistic assessment), I still think he's the right candidate.
> >
> > I'm not going to ask the ML (or anybody, for that matter) to admonish him for his behavior. He's
> > done a lot for OFBiz, and I'd honestly say he should take his Manufacturing module away with him
> > if we're to ask him to go away. I don't want him to go away. I don't want to be put in that
> > difficult position, so that's why I wouldn't want David in that position either. Well there I go
> > again, that same style. :) If Jacopo goes, OFBiz will not hold enough value for me and my bosses.
> >
> > As for really rubbing some people the wrong way, I guess it has a lot to do with the fact that
> > I've weaned myself (and my bosses and future bosses) from dependence on ML tech support (yes, it
> > was officially deemed a non-support channel some weeks back). And possibly even more because I
> > unwittingly "damaged" the business model for some people here. I honestly didn't know at first the
> > technical references for OFBiz are only sold commercially. Upon realizing it, I had then consulted
> > David privately to ask if there's anything I can do (eg NOT publish my altruistic
> > yet-to-be-written Engineer's Manual) if it meant righting an imbalance in "give-and-take"
> > situation between OFBiz and users. David said it's Undersun that's profiting from those
> > commercially sold tech references, not OFBiz.
> >
> > (I hope the dev list doesn't have paid customers, because some did complain about the tech
> > references sold. I have never seen those references, and can't comment. Would've wanted this post
> > to be private, but maybe I should really be perfectly honest for a change. Bosses would fry me if
> > they bought those references owing to my comments or the lack thereof, so I have to say I'm
> > neither arguing against nor for those references.)
> >
> > Please understand that I had no option to avoid taking apart OFBiz and weaning my bosses from
> > reliance on a "difficult channel" for tech support. It was about the only way I could keep them
> > from chucking OFBiz in the trash. And maybe I should be honest (but I thought I'd mentioned this
> > several times) about my occupation; I'm a LEGAL reverse-engineer by trade (not just Java
> > compiled/source codes). If there's an implicit ban againt reverse-engineers in ML, please let me
> > know and I'll gladly oblige. This isn't my grandfather's ML. (There, same style again.)
> >
> > I will certainly take your suggestions seriously, and heed your call for us to "come
> > [cooperate/play] together". However, I do hope the ML can appreciate that I'm caught in a
> > difficult in-between position, and my comments on the ML cannot deviate too far from "honest
> > business sense". I'd have thought my arguments for OFBiz are all the more potent precisely because
> > of my stark objectivity. And that appears to be the case (for now), since my bosses haven't turned
> > away from OFBiz yet.
> >
> > I hope that this thread being on the dev list will mean it will stop here. I wouldn't want another
> > "baggin on OFBiz" session (you know my stakes in OFBiz). If it does spark a rowdy discussion, I'll
> > be the first to call for a stop to that.
> >
> > One important note about the ML. I have noticed it's probably hard for some people to scan through
> > surrounding contexts (posts related to a post) when responding to a post. Perhaps that's where the
> > problem is?
> >
> > I hope we understand each other more from this.
> >
> > Jonathon
> >
> > Tim Ruppert wrote:
> > > Jonathon as an innocent bystander, all I can say is that with every word
> > > you type you are rubbing people the wrong way. Please just take a
> > > moment to read thru your posts before hitting send - and think about the
> > > fact that there are tons of people here from different backgrounds who
> > > are pushing towards the same goal.
> > >
> > > I realize that your intentions are good and that you're working towards
> > > that same goal, but understand that if you're rubbing everyone the wrong
> > > way - it might not be them, but how you're choosing to phrase your
> > > questions, comments and concerns.
> > >
> > > All I ask is that you think about what you're saying and where you
> > > really want things to go and phrase things accordingly. I'm not saying
> > > that all responses to your digging have been phrased smoothly - but you
> > > can only control yourself - so let's all give it a try.
> > >
> > > This is not totally relevant, but I believe I wrote this up sometime
> > > around the last episode people rubbing others the wrong way on the dev
> > > list
> > > - http://www.nabble.com/Why's-everybody-baggin'-on-OFBiz-lately-t3081858.html
> > >
> > > Anyways, I hope you read this for what it is - a request to come
> > > together - and you take my suggestions seriously. Thanks for posting
> > > Jonathon and we look forward to more helpful things out of your in the
> > > future.
> > >
> > > Cheers,
> > > Tim
> > > --
> > > Tim Ruppert
> > > HotWax Media
> > > http://www.hotwaxmedia.com
> > >
> > > o:801.649.6594
> > > f:801.649.6595
> > >
> > >
> > > On Feb 7, 2007, at 3:27 AM, Jonathon -- Improov wrote:
> > >
> > >> Jacopo,
> > >>
> > >> No, I'm not trolling. Are you?
> > >>
> > >> If you meant the last concise post to you, it's because I know you're
> > >> really really busy. Just a sincere effort to cut down on "extras" in
> > >> my writing to you.
> > >>
> > >> If you meant my comment on David's and Si Chen's discussion, like I
> > >> said, you better re-read for yourself. I'd rather not repeat something
> > >> so often it seems like I'm rubbing a fact in or something.
> > >>
> > >> If you're still miffed for some reason, I'll say sorry again. But I
> > >> think we both better watch out, and stop this somewhere sometime soon.
> > >> Or both of us will be accused of messing up!
> > >>
> > >> As I said, all posts are cached or read or otherwise recorded or
> > >> witnessed by others. We should both take a step back and re-read past
> > >> posts in order to avoid further misunderstanding.
> > >>
> > >> My actions are plain for all to see, and so are yours. We should both
> > >> behave ourselves. Agree? :)
> > >>
> > >> Jonathon
> > >>
> > >> Jacopo Cappellato wrote:
> > >>> Jonathon,
> > >>> are you trolling?
> > >>> Jacopo
> > >>> Jonathon -- Improov wrote:
> > >>>> Er, Jacopo. Maybe I moved your cheese some time, I don't know. If
> > >>>> so, sorry!
> > >>>>
> > >>>> Since you like conciseness, please re-read this thread between David
> > >>>> and Si Chen.
> > >>>>
> > >>>> As for incorrect information, re-read my previous posts.
> > >>>>
> > >>>> Jonathon
> > >>>>
> > >>>> Jacopo Cappellato wrote:
> > >>>>> Jonathon -- Improov wrote:
> > >>>>>> Si Chen,
> > >>>>>>
> > >>>>>> I wasn't "saying" anything.
> > >>>>>
> > >>>>> I think that this is the problem with many of your (and with those
> > >>>>> of some new guys that recently are around in these lists) posts,
> > >>>>> Jonathon: you say nothing with too many words, and this is
> > >>>>> confusing, especially for new users and, in the dev list, it is
> > >>>>> annoying because it's difficult to concentrate and discuss on the
> > >>>>> development of OFBiz.
> > >>>>> There is no need to comment every post and in general silence is
> > >>>>> better than incorrect or partially correct information.
> > >>>>>
> > >>>>> Jacopo
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>
> > >
> >
> --
> Kind Regards
> Andrew Sykes <an...@sykesdevelopment.com>
> Sykes Development Ltd
> http://www.sykesdevelopment.com
Re: svn commit: r502824 -
/ofbiz/trunk/applications/product/script/org/ofbiz/product/inventory/InventoryReserveServices.xml
Posted by Andrew Sykes <an...@sykesdevelopment.com>.
Please please guys, just drop this,
I'm sure none of us who are having to delete all this nonsense really
care.
- Andrew
On Thu, 2007-02-08 at 06:56 +0800, Jonathon -- Improov wrote:
> Tim, Jacopo,
>
> Well, since you put this in the open, I guess I might as well re-examine my previous posts.
>
> In Jacopo's case, it all did start out with me appreciating his help. In one of my first posts, I
> made the mistake of recalling that it was Jacopo who corrected me on the "please use absolute path
> in your diff/patches". Jacques informed us it was actually him. Incidentally, you'll note that I
> always use myself and my own mistakes to illustrate "how things should be done". That particular
> post was in a thread where David was suggesting a pre-commit review or lamenting the lack thereof.
>
> Anyway, you'll see the same styles everywhere. Any to-the-point criticisms are first directed at
> myself, sometimes even almost deviating from the truth in cases where I wasn't quite able to find
> an example that qualifies myself as a target for said criticisms. At times, I may even have
> stretched the truth about myself in order to "smooth things out", and could've been accused of
> hypocrisy. For eg, I do have the tendency to admit to wrongdoing to some extent in order to "let
> the dust settle". I wouldn't state the exact audience that witnessed this style (and the responses
> to it) on this ML, but I can tell you that you can consider my tact universally acknowledged (and
> in some cases even disapproved of, because the tact gave way to ill reason and bordered on letting
> dishonesty take the final note.) Yes, my boss or bosses (future/potential ones) are in that
> audience. Part of that audience also includes Singaporean companies deciding whether they want to
> go with OFBiz.
>
> (And for the record, to be clearly honest for a change, things are not looking good at all. Yes,
> they're watching every message I type, so you should know I'm your biggest proponent here. Stuck
> in a difficult in-between place.)
>
> Back to Jacopo's case. One of the first "good rubs" with Jacopo was with the Product Variant BOMs
> help from Jacopo. In fact, about the biggest reason my current boss is still with OFBiz is because
> of his work in Manufacturing module. As I mentioned in a post to David, we're watching Jacopo; I
> recommended him to cover for me in tech support once my project is done. After all, my boss is in
> manufacturing and Jacopo has done a lot there. Despite his recent display (we're still comparing
> with his past posts way back for a more holistic assessment), I still think he's the right candidate.
>
> I'm not going to ask the ML (or anybody, for that matter) to admonish him for his behavior. He's
> done a lot for OFBiz, and I'd honestly say he should take his Manufacturing module away with him
> if we're to ask him to go away. I don't want him to go away. I don't want to be put in that
> difficult position, so that's why I wouldn't want David in that position either. Well there I go
> again, that same style. :) If Jacopo goes, OFBiz will not hold enough value for me and my bosses.
>
> As for really rubbing some people the wrong way, I guess it has a lot to do with the fact that
> I've weaned myself (and my bosses and future bosses) from dependence on ML tech support (yes, it
> was officially deemed a non-support channel some weeks back). And possibly even more because I
> unwittingly "damaged" the business model for some people here. I honestly didn't know at first the
> technical references for OFBiz are only sold commercially. Upon realizing it, I had then consulted
> David privately to ask if there's anything I can do (eg NOT publish my altruistic
> yet-to-be-written Engineer's Manual) if it meant righting an imbalance in "give-and-take"
> situation between OFBiz and users. David said it's Undersun that's profiting from those
> commercially sold tech references, not OFBiz.
>
> (I hope the dev list doesn't have paid customers, because some did complain about the tech
> references sold. I have never seen those references, and can't comment. Would've wanted this post
> to be private, but maybe I should really be perfectly honest for a change. Bosses would fry me if
> they bought those references owing to my comments or the lack thereof, so I have to say I'm
> neither arguing against nor for those references.)
>
> Please understand that I had no option to avoid taking apart OFBiz and weaning my bosses from
> reliance on a "difficult channel" for tech support. It was about the only way I could keep them
> from chucking OFBiz in the trash. And maybe I should be honest (but I thought I'd mentioned this
> several times) about my occupation; I'm a LEGAL reverse-engineer by trade (not just Java
> compiled/source codes). If there's an implicit ban againt reverse-engineers in ML, please let me
> know and I'll gladly oblige. This isn't my grandfather's ML. (There, same style again.)
>
> I will certainly take your suggestions seriously, and heed your call for us to "come
> [cooperate/play] together". However, I do hope the ML can appreciate that I'm caught in a
> difficult in-between position, and my comments on the ML cannot deviate too far from "honest
> business sense". I'd have thought my arguments for OFBiz are all the more potent precisely because
> of my stark objectivity. And that appears to be the case (for now), since my bosses haven't turned
> away from OFBiz yet.
>
> I hope that this thread being on the dev list will mean it will stop here. I wouldn't want another
> "baggin on OFBiz" session (you know my stakes in OFBiz). If it does spark a rowdy discussion, I'll
> be the first to call for a stop to that.
>
> One important note about the ML. I have noticed it's probably hard for some people to scan through
> surrounding contexts (posts related to a post) when responding to a post. Perhaps that's where the
> problem is?
>
> I hope we understand each other more from this.
>
> Jonathon
>
> Tim Ruppert wrote:
> > Jonathon as an innocent bystander, all I can say is that with every word
> > you type you are rubbing people the wrong way. Please just take a
> > moment to read thru your posts before hitting send - and think about the
> > fact that there are tons of people here from different backgrounds who
> > are pushing towards the same goal.
> >
> > I realize that your intentions are good and that you're working towards
> > that same goal, but understand that if you're rubbing everyone the wrong
> > way - it might not be them, but how you're choosing to phrase your
> > questions, comments and concerns.
> >
> > All I ask is that you think about what you're saying and where you
> > really want things to go and phrase things accordingly. I'm not saying
> > that all responses to your digging have been phrased smoothly - but you
> > can only control yourself - so let's all give it a try.
> >
> > This is not totally relevant, but I believe I wrote this up sometime
> > around the last episode people rubbing others the wrong way on the dev
> > list
> > - http://www.nabble.com/Why's-everybody-baggin'-on-OFBiz-lately-t3081858.html
> >
> > Anyways, I hope you read this for what it is - a request to come
> > together - and you take my suggestions seriously. Thanks for posting
> > Jonathon and we look forward to more helpful things out of your in the
> > future.
> >
> > Cheers,
> > Tim
> > --
> > Tim Ruppert
> > HotWax Media
> > http://www.hotwaxmedia.com
> >
> > o:801.649.6594
> > f:801.649.6595
> >
> >
> > On Feb 7, 2007, at 3:27 AM, Jonathon -- Improov wrote:
> >
> >> Jacopo,
> >>
> >> No, I'm not trolling. Are you?
> >>
> >> If you meant the last concise post to you, it's because I know you're
> >> really really busy. Just a sincere effort to cut down on "extras" in
> >> my writing to you.
> >>
> >> If you meant my comment on David's and Si Chen's discussion, like I
> >> said, you better re-read for yourself. I'd rather not repeat something
> >> so often it seems like I'm rubbing a fact in or something.
> >>
> >> If you're still miffed for some reason, I'll say sorry again. But I
> >> think we both better watch out, and stop this somewhere sometime soon.
> >> Or both of us will be accused of messing up!
> >>
> >> As I said, all posts are cached or read or otherwise recorded or
> >> witnessed by others. We should both take a step back and re-read past
> >> posts in order to avoid further misunderstanding.
> >>
> >> My actions are plain for all to see, and so are yours. We should both
> >> behave ourselves. Agree? :)
> >>
> >> Jonathon
> >>
> >> Jacopo Cappellato wrote:
> >>> Jonathon,
> >>> are you trolling?
> >>> Jacopo
> >>> Jonathon -- Improov wrote:
> >>>> Er, Jacopo. Maybe I moved your cheese some time, I don't know. If
> >>>> so, sorry!
> >>>>
> >>>> Since you like conciseness, please re-read this thread between David
> >>>> and Si Chen.
> >>>>
> >>>> As for incorrect information, re-read my previous posts.
> >>>>
> >>>> Jonathon
> >>>>
> >>>> Jacopo Cappellato wrote:
> >>>>> Jonathon -- Improov wrote:
> >>>>>> Si Chen,
> >>>>>>
> >>>>>> I wasn't "saying" anything.
> >>>>>
> >>>>> I think that this is the problem with many of your (and with those
> >>>>> of some new guys that recently are around in these lists) posts,
> >>>>> Jonathon: you say nothing with too many words, and this is
> >>>>> confusing, especially for new users and, in the dev list, it is
> >>>>> annoying because it's difficult to concentrate and discuss on the
> >>>>> development of OFBiz.
> >>>>> There is no need to comment every post and in general silence is
> >>>>> better than incorrect or partially correct information.
> >>>>>
> >>>>> Jacopo
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>
> >
>
--
Kind Regards
Andrew Sykes <an...@sykesdevelopment.com>
Sykes Development Ltd
http://www.sykesdevelopment.com
Re: svn commit: r502824 - /ofbiz/trunk/applications/product/script/org/ofbiz/product/inventory/InventoryReserveServices.xml
Posted by Tim Ruppert <ti...@hotwaxmedia.com>.
Jonathon as an innocent bystander, all I can say is that with every
word you type you are rubbing people the wrong way. Please just take
a moment to read thru your posts before hitting send - and think
about the fact that there are tons of people here from different
backgrounds who are pushing towards the same goal.
I realize that your intentions are good and that you're working
towards that same goal, but understand that if you're rubbing
everyone the wrong way - it might not be them, but how you're
choosing to phrase your questions, comments and concerns.
All I ask is that you think about what you're saying and where you
really want things to go and phrase things accordingly. I'm not
saying that all responses to your digging have been phrased smoothly
- but you can only control yourself - so let's all give it a try.
This is not totally relevant, but I believe I wrote this up sometime
around the last episode people rubbing others the wrong way on the
dev list - http://www.nabble.com/Why's-everybody-baggin'-on-OFBiz-
lately-t3081858.html
Anyways, I hope you read this for what it is - a request to come
together - and you take my suggestions seriously. Thanks for posting
Jonathon and we look forward to more helpful things out of your in
the future.
Cheers,
Tim
--
Tim Ruppert
HotWax Media
http://www.hotwaxmedia.com
o:801.649.6594
f:801.649.6595
On Feb 7, 2007, at 3:27 AM, Jonathon -- Improov wrote:
> Jacopo,
>
> No, I'm not trolling. Are you?
>
> If you meant the last concise post to you, it's because I know
> you're really really busy. Just a sincere effort to cut down on
> "extras" in my writing to you.
>
> If you meant my comment on David's and Si Chen's discussion, like I
> said, you better re-read for yourself. I'd rather not repeat
> something so often it seems like I'm rubbing a fact in or something.
>
> If you're still miffed for some reason, I'll say sorry again. But I
> think we both better watch out, and stop this somewhere sometime
> soon. Or both of us will be accused of messing up!
>
> As I said, all posts are cached or read or otherwise recorded or
> witnessed by others. We should both take a step back and re-read
> past posts in order to avoid further misunderstanding.
>
> My actions are plain for all to see, and so are yours. We should
> both behave ourselves. Agree? :)
>
> Jonathon
>
> Jacopo Cappellato wrote:
>> Jonathon,
>> are you trolling?
>> Jacopo
>> Jonathon -- Improov wrote:
>>> Er, Jacopo. Maybe I moved your cheese some time, I don't know. If
>>> so, sorry!
>>>
>>> Since you like conciseness, please re-read this thread between
>>> David and Si Chen.
>>>
>>> As for incorrect information, re-read my previous posts.
>>>
>>> Jonathon
>>>
>>> Jacopo Cappellato wrote:
>>>> Jonathon -- Improov wrote:
>>>>> Si Chen,
>>>>>
>>>>> I wasn't "saying" anything.
>>>>
>>>> I think that this is the problem with many of your (and with
>>>> those of some new guys that recently are around in these lists)
>>>> posts, Jonathon: you say nothing with too many words, and this
>>>> is confusing, especially for new users and, in the dev list, it
>>>> is annoying because it's difficult to concentrate and discuss on
>>>> the development of OFBiz.
>>>> There is no need to comment every post and in general silence is
>>>> better than incorrect or partially correct information.
>>>>
>>>> Jacopo
>>>>
>>>>
>>>>
>>>>
>
Re: svn commit: r502824 - /ofbiz/trunk/applications/product/script/org/ofbiz/product/inventory/InventoryReserveServices.xml
Posted by Jonathon -- Improov <jo...@improov.com>.
Jacopo,
No, I'm not trolling. Are you?
If you meant the last concise post to you, it's because I know you're really really busy. Just a
sincere effort to cut down on "extras" in my writing to you.
If you meant my comment on David's and Si Chen's discussion, like I said, you better re-read for
yourself. I'd rather not repeat something so often it seems like I'm rubbing a fact in or something.
If you're still miffed for some reason, I'll say sorry again. But I think we both better watch
out, and stop this somewhere sometime soon. Or both of us will be accused of messing up!
As I said, all posts are cached or read or otherwise recorded or witnessed by others. We should
both take a step back and re-read past posts in order to avoid further misunderstanding.
My actions are plain for all to see, and so are yours. We should both behave ourselves. Agree? :)
Jonathon
Jacopo Cappellato wrote:
> Jonathon,
>
> are you trolling?
>
> Jacopo
>
> Jonathon -- Improov wrote:
>> Er, Jacopo. Maybe I moved your cheese some time, I don't know. If so,
>> sorry!
>>
>> Since you like conciseness, please re-read this thread between David
>> and Si Chen.
>>
>> As for incorrect information, re-read my previous posts.
>>
>> Jonathon
>>
>> Jacopo Cappellato wrote:
>>> Jonathon -- Improov wrote:
>>>> Si Chen,
>>>>
>>>> I wasn't "saying" anything.
>>>
>>> I think that this is the problem with many of your (and with those of
>>> some new guys that recently are around in these lists) posts,
>>> Jonathon: you say nothing with too many words, and this is confusing,
>>> especially for new users and, in the dev list, it is annoying because
>>> it's difficult to concentrate and discuss on the development of OFBiz.
>>> There is no need to comment every post and in general silence is
>>> better than incorrect or partially correct information.
>>>
>>> Jacopo
>>>
>>>
>>>
>>>
>
>
>
Re: svn commit: r502824 - /ofbiz/trunk/applications/product/script/org/ofbiz/product/inventory/InventoryReserveServices.xml
Posted by Jacopo Cappellato <ti...@sastau.it>.
Jonathon,
are you trolling?
Jacopo
Jonathon -- Improov wrote:
> Er, Jacopo. Maybe I moved your cheese some time, I don't know. If so,
> sorry!
>
> Since you like conciseness, please re-read this thread between David and
> Si Chen.
>
> As for incorrect information, re-read my previous posts.
>
> Jonathon
>
> Jacopo Cappellato wrote:
>> Jonathon -- Improov wrote:
>>> Si Chen,
>>>
>>> I wasn't "saying" anything.
>>
>> I think that this is the problem with many of your (and with those of
>> some new guys that recently are around in these lists) posts,
>> Jonathon: you say nothing with too many words, and this is confusing,
>> especially for new users and, in the dev list, it is annoying because
>> it's difficult to concentrate and discuss on the development of OFBiz.
>> There is no need to comment every post and in general silence is
>> better than incorrect or partially correct information.
>>
>> Jacopo
>>
>>
>>
>>
Re: svn commit: r502824 - /ofbiz/trunk/applications/product/script/org/ofbiz/product/inventory/InventoryReserveServices.xml
Posted by Jonathon -- Improov <jo...@improov.com>.
Er, Jacopo. Maybe I moved your cheese some time, I don't know. If so, sorry!
Since you like conciseness, please re-read this thread between David and Si Chen.
As for incorrect information, re-read my previous posts.
Jonathon
Jacopo Cappellato wrote:
> Jonathon -- Improov wrote:
>> Si Chen,
>>
>> I wasn't "saying" anything.
>
> I think that this is the problem with many of your (and with those of
> some new guys that recently are around in these lists) posts, Jonathon:
> you say nothing with too many words, and this is confusing, especially
> for new users and, in the dev list, it is annoying because it's
> difficult to concentrate and discuss on the development of OFBiz.
> There is no need to comment every post and in general silence is better
> than incorrect or partially correct information.
>
> Jacopo
>
>
>
>
Re: svn commit: r502824 - /ofbiz/trunk/applications/product/script/org/ofbiz/product/inventory/InventoryReserveServices.xml
Posted by Jacopo Cappellato <ti...@sastau.it>.
Jonathon -- Improov wrote:
> Si Chen,
>
> I wasn't "saying" anything.
I think that this is the problem with many of your (and with those of
some new guys that recently are around in these lists) posts, Jonathon:
you say nothing with too many words, and this is confusing, especially
for new users and, in the dev list, it is annoying because it's
difficult to concentrate and discuss on the development of OFBiz.
There is no need to comment every post and in general silence is better
than incorrect or partially correct information.
Jacopo
Re: svn commit: r502824 - /ofbiz/trunk/applications/product/script/org/ofbiz/product/inventory/InventoryReserveServices.xml
Posted by Jonathon -- Improov <jo...@improov.com>.
Si Chen,
> You're welcome to have and express whatever opinion you wish, but what
> you are saying is not true.
I wasn't "saying" anything. I was observing the fact that it seemed there was gonna be a change to
something core. I've not known "+/-" to be a standard SQL notation, and quickly assumed there was
another layer above PostgreSQL that handled the "+/-". This layer being most likely in OFBiz
framework.
Hmm. Maybe I should check the definition for the word "observe".
Sorry if I caused any misunderstanding.
Jonathon
Si Chen wrote:
> Jonathon -- Improov wrote:
>> David, Si Chen,
>>
>> Just to let you know my impression as an observer of this thread.
>>
>> I was shocked to read "the +/- notation does not work well with
>> PostgreSQL". Was bracing myself for a tidal wave of a change in the
>> OFBiz framework.
>>
>> Jonathon
>>
>> David E. Jones wrote:
>>>
>>> On Feb 5, 2007, at 10:16 AM, Si Chen wrote:
>>>
>>>> David E. Jones wrote:
>>>>>
>>>>> Hold on a minute there.... did you actually test and find this to
>>>>> be a problem? The +/- notation is an entity engine ONLY thing and
>>>>> should never make it to the database.
>>>>>
>>>>> This patch should be reverted and if +/- are making it to the
>>>>> database instead of being replaced with an ASC/DESC by the entity
>>>>> engine then THAT bug should be fixed.
>>>>>
>>>>> This is a slippery slope and we should backup to the top before it
>>>>> gets going...
>>>>>
>>>>> -David
>>>>>
>>>>> On Feb 2, 2007, at 6:16 PM, sichen@apache.org wrote:
>>>>>
>>>>>> Author: sichen
>>>>>> Date: Fri Feb 2 17:16:36 2007
>>>>>> New Revision: 502824
>>>>>>
>>>>>> URL: http://svn.apache.org/viewvc?view=rev&rev=502824
>>>>>> Log:
>>>>>> Fix a pretty significant bug with sequence of inventory item
>>>>>> reservations for orders: FIFO and LIFO were reversed (I checked
>>>>>> this) and the +/- notation does not work well with PostgreSQL
>>>>>>
>>>>>> Modified:
>>>>>>
>>>>>> ofbiz/trunk/applications/product/script/org/ofbiz/product/inventory/InventoryReserveServices.xml
>>>>>>
>>>>>>
>>>>>> Modified:
>>>>>> ofbiz/trunk/applications/product/script/org/ofbiz/product/inventory/InventoryReserveServices.xml
>>>>>>
>>>>>
>>>> David,
>>>>
>>>> I worked on this with Leon, and we did test this a few times, and
>>>> the inventory reservation sequence was wrong. Previously when
>>>> using the FIFO reservation, the last item received was being
>>>> reserved against orders. It seems that "-datetimeReceived" was
>>>> ordering them by descending order of date time received, and as a
>>>> result reservations were done in the wrong sequence.
>>>>
>>>> We did not realize that the + or - notation were an entity engine
>>>> thing, but please test the actual reservation of inventory before
>>>> and after this patch and let us know which behavior you feel is
>>>> correct. I realize this is a pretty basic fix to an existing
>>>> feature, and I had trouble believing that something like this could
>>>> be broken, but we did try it several times ourselves.
>>>> Si
>>>
>>> Perhaps I should have been more explicit in my comment. I was
>>> referring only to the apparent bug report about the +/- notation on
>>> certain databases, including Postgres.
>>>
>>> My comments did not mention nor had anything to do with the fix of
>>> the inventory reservation sequence, and it's great that you guys
>>> found and fixed that bug. It looks like the _REC reserve orders were
>>> added to the original code but not implemented correctly, so yeah,
>>> it's great that you took care of that.
>>>
>>> -David
>>>
>>
> Jonathon,
>
> You're welcome to have and express whatever opinion you wish, but what
> you are saying is not true.
>
>
> Si
>
>
Re: svn commit: r502824 - /ofbiz/trunk/applications/product/script/org/ofbiz/product/inventory/InventoryReserveServices.xml
Posted by Si Chen <si...@opensourcestrategies.com>.
Jonathon -- Improov wrote:
> David, Si Chen,
>
> Just to let you know my impression as an observer of this thread.
>
> I was shocked to read "the +/- notation does not work well with
> PostgreSQL". Was bracing myself for a tidal wave of a change in the
> OFBiz framework.
>
> Jonathon
>
> David E. Jones wrote:
>>
>> On Feb 5, 2007, at 10:16 AM, Si Chen wrote:
>>
>>> David E. Jones wrote:
>>>>
>>>> Hold on a minute there.... did you actually test and find this to
>>>> be a problem? The +/- notation is an entity engine ONLY thing and
>>>> should never make it to the database.
>>>>
>>>> This patch should be reverted and if +/- are making it to the
>>>> database instead of being replaced with an ASC/DESC by the entity
>>>> engine then THAT bug should be fixed.
>>>>
>>>> This is a slippery slope and we should backup to the top before it
>>>> gets going...
>>>>
>>>> -David
>>>>
>>>> On Feb 2, 2007, at 6:16 PM, sichen@apache.org wrote:
>>>>
>>>>> Author: sichen
>>>>> Date: Fri Feb 2 17:16:36 2007
>>>>> New Revision: 502824
>>>>>
>>>>> URL: http://svn.apache.org/viewvc?view=rev&rev=502824
>>>>> Log:
>>>>> Fix a pretty significant bug with sequence of inventory item
>>>>> reservations for orders: FIFO and LIFO were reversed (I checked
>>>>> this) and the +/- notation does not work well with PostgreSQL
>>>>>
>>>>> Modified:
>>>>>
>>>>> ofbiz/trunk/applications/product/script/org/ofbiz/product/inventory/InventoryReserveServices.xml
>>>>>
>>>>>
>>>>> Modified:
>>>>> ofbiz/trunk/applications/product/script/org/ofbiz/product/inventory/InventoryReserveServices.xml
>>>>>
>>>>
>>> David,
>>>
>>> I worked on this with Leon, and we did test this a few times, and
>>> the inventory reservation sequence was wrong. Previously when
>>> using the FIFO reservation, the last item received was being
>>> reserved against orders. It seems that "-datetimeReceived" was
>>> ordering them by descending order of date time received, and as a
>>> result reservations were done in the wrong sequence.
>>>
>>> We did not realize that the + or - notation were an entity engine
>>> thing, but please test the actual reservation of inventory before
>>> and after this patch and let us know which behavior you feel is
>>> correct. I realize this is a pretty basic fix to an existing
>>> feature, and I had trouble believing that something like this could
>>> be broken, but we did try it several times ourselves.
>>> Si
>>
>> Perhaps I should have been more explicit in my comment. I was
>> referring only to the apparent bug report about the +/- notation on
>> certain databases, including Postgres.
>>
>> My comments did not mention nor had anything to do with the fix of
>> the inventory reservation sequence, and it's great that you guys
>> found and fixed that bug. It looks like the _REC reserve orders were
>> added to the original code but not implemented correctly, so yeah,
>> it's great that you took care of that.
>>
>> -David
>>
>
Jonathon,
You're welcome to have and express whatever opinion you wish, but what
you are saying is not true.
Si
Re: svn commit: r502824 - /ofbiz/trunk/applications/product/script/org/ofbiz/product/inventory/InventoryReserveServices.xml
Posted by Jonathon -- Improov <jo...@improov.com>.
David, Si Chen,
Just to let you know my impression as an observer of this thread.
I was shocked to read "the +/- notation does not work well with PostgreSQL". Was bracing myself
for a tidal wave of a change in the OFBiz framework.
Jonathon
David E. Jones wrote:
>
> On Feb 5, 2007, at 10:16 AM, Si Chen wrote:
>
>> David E. Jones wrote:
>>>
>>> Hold on a minute there.... did you actually test and find this to be
>>> a problem? The +/- notation is an entity engine ONLY thing and should
>>> never make it to the database.
>>>
>>> This patch should be reverted and if +/- are making it to the
>>> database instead of being replaced with an ASC/DESC by the entity
>>> engine then THAT bug should be fixed.
>>>
>>> This is a slippery slope and we should backup to the top before it
>>> gets going...
>>>
>>> -David
>>>
>>> On Feb 2, 2007, at 6:16 PM, sichen@apache.org wrote:
>>>
>>>> Author: sichen
>>>> Date: Fri Feb 2 17:16:36 2007
>>>> New Revision: 502824
>>>>
>>>> URL: http://svn.apache.org/viewvc?view=rev&rev=502824
>>>> Log:
>>>> Fix a pretty significant bug with sequence of inventory item
>>>> reservations for orders: FIFO and LIFO were reversed (I checked
>>>> this) and the +/- notation does not work well with PostgreSQL
>>>>
>>>> Modified:
>>>>
>>>> ofbiz/trunk/applications/product/script/org/ofbiz/product/inventory/InventoryReserveServices.xml
>>>>
>>>>
>>>> Modified:
>>>> ofbiz/trunk/applications/product/script/org/ofbiz/product/inventory/InventoryReserveServices.xml
>>>>
>>>
>> David,
>>
>> I worked on this with Leon, and we did test this a few times, and the
>> inventory reservation sequence was wrong. Previously when using the
>> FIFO reservation, the last item received was being reserved against
>> orders. It seems that "-datetimeReceived" was ordering them by
>> descending order of date time received, and as a result reservations
>> were done in the wrong sequence.
>>
>> We did not realize that the + or - notation were an entity engine
>> thing, but please test the actual reservation of inventory before and
>> after this patch and let us know which behavior you feel is correct.
>> I realize this is a pretty basic fix to an existing feature, and I had
>> trouble believing that something like this could be broken, but we did
>> try it several times ourselves.
>> Si
>
> Perhaps I should have been more explicit in my comment. I was referring
> only to the apparent bug report about the +/- notation on certain
> databases, including Postgres.
>
> My comments did not mention nor had anything to do with the fix of the
> inventory reservation sequence, and it's great that you guys found and
> fixed that bug. It looks like the _REC reserve orders were added to the
> original code but not implemented correctly, so yeah, it's great that
> you took care of that.
>
> -David
>
Re: svn commit: r502824 - /ofbiz/trunk/applications/product/script/org/ofbiz/product/inventory/InventoryReserveServices.xml
Posted by Si Chen <si...@opensourcestrategies.com>.
David E. Jones wrote:
>
> On Feb 5, 2007, at 10:16 AM, Si Chen wrote:
>
>> David E. Jones wrote:
>>>
>>> Hold on a minute there.... did you actually test and find this to be
>>> a problem? The +/- notation is an entity engine ONLY thing and
>>> should never make it to the database.
>>>
>>> This patch should be reverted and if +/- are making it to the
>>> database instead of being replaced with an ASC/DESC by the entity
>>> engine then THAT bug should be fixed.
>>>
>>> This is a slippery slope and we should backup to the top before it
>>> gets going...
>>>
>>> -David
>>>
>>> On Feb 2, 2007, at 6:16 PM, sichen@apache.org wrote:
>>>
>>>> Author: sichen
>>>> Date: Fri Feb 2 17:16:36 2007
>>>> New Revision: 502824
>>>>
>>>> URL: http://svn.apache.org/viewvc?view=rev&rev=502824
>>>> Log:
>>>> Fix a pretty significant bug with sequence of inventory item
>>>> reservations for orders: FIFO and LIFO were reversed (I checked
>>>> this) and the +/- notation does not work well with PostgreSQL
>>>>
>>>> Modified:
>>>>
>>>> ofbiz/trunk/applications/product/script/org/ofbiz/product/inventory/InventoryReserveServices.xml
>>>>
>>>>
>>>> Modified:
>>>> ofbiz/trunk/applications/product/script/org/ofbiz/product/inventory/InventoryReserveServices.xml
>>>>
>>>
>> David,
>>
>> I worked on this with Leon, and we did test this a few times, and the
>> inventory reservation sequence was wrong. Previously when using the
>> FIFO reservation, the last item received was being reserved against
>> orders. It seems that "-datetimeReceived" was ordering them by
>> descending order of date time received, and as a result reservations
>> were done in the wrong sequence.
>>
>> We did not realize that the + or - notation were an entity engine
>> thing, but please test the actual reservation of inventory before and
>> after this patch and let us know which behavior you feel is correct.
>> I realize this is a pretty basic fix to an existing feature, and I
>> had trouble believing that something like this could be broken, but
>> we did try it several times ourselves.
>> Si
>
> Perhaps I should have been more explicit in my comment. I was
> referring only to the apparent bug report about the +/- notation on
> certain databases, including Postgres.
>
> My comments did not mention nor had anything to do with the fix of the
> inventory reservation sequence, and it's great that you guys found and
> fixed that bug. It looks like the _REC reserve orders were added to
> the original code but not implemented correctly, so yeah, it's great
> that you took care of that.
>
> -David
>
Ok. Actually I do not think there is a problem with +/- notation. I
was trying to figure out what was wrong with the inventory reservation
and realized that it was not a postgresql notation, so I made a comment
about it on my commit, but I don't have any reason to believe it's a
source of problem.
Re: svn commit: r502824 - /ofbiz/trunk/applications/product/script/org/ofbiz/product/inventory/InventoryReserveServices.xml
Posted by "David E. Jones" <jo...@hotwaxmedia.com>.
On Feb 5, 2007, at 10:16 AM, Si Chen wrote:
> David E. Jones wrote:
>>
>> Hold on a minute there.... did you actually test and find this to
>> be a problem? The +/- notation is an entity engine ONLY thing and
>> should never make it to the database.
>>
>> This patch should be reverted and if +/- are making it to the
>> database instead of being replaced with an ASC/DESC by the entity
>> engine then THAT bug should be fixed.
>>
>> This is a slippery slope and we should backup to the top before it
>> gets going...
>>
>> -David
>>
>> On Feb 2, 2007, at 6:16 PM, sichen@apache.org wrote:
>>
>>> Author: sichen
>>> Date: Fri Feb 2 17:16:36 2007
>>> New Revision: 502824
>>>
>>> URL: http://svn.apache.org/viewvc?view=rev&rev=502824
>>> Log:
>>> Fix a pretty significant bug with sequence of inventory item
>>> reservations for orders: FIFO and LIFO were reversed (I checked
>>> this) and the +/- notation does not work well with PostgreSQL
>>>
>>> Modified:
>>> ofbiz/trunk/applications/product/script/org/ofbiz/product/
>>> inventory/InventoryReserveServices.xml
>>>
>>> Modified: ofbiz/trunk/applications/product/script/org/ofbiz/
>>> product/inventory/InventoryReserveServices.xml
>>
> David,
>
> I worked on this with Leon, and we did test this a few times, and
> the inventory reservation sequence was wrong. Previously when
> using the FIFO reservation, the last item received was being
> reserved against orders. It seems that "-datetimeReceived" was
> ordering them by descending order of date time received, and as a
> result reservations were done in the wrong sequence.
>
> We did not realize that the + or - notation were an entity engine
> thing, but please test the actual reservation of inventory before
> and after this patch and let us know which behavior you feel is
> correct. I realize this is a pretty basic fix to an existing
> feature, and I had trouble believing that something like this could
> be broken, but we did try it several times ourselves.
> Si
Perhaps I should have been more explicit in my comment. I was
referring only to the apparent bug report about the +/- notation on
certain databases, including Postgres.
My comments did not mention nor had anything to do with the fix of
the inventory reservation sequence, and it's great that you guys
found and fixed that bug. It looks like the _REC reserve orders were
added to the original code but not implemented correctly, so yeah,
it's great that you took care of that.
-David
Re: svn commit: r502824 - /ofbiz/trunk/applications/product/script/org/ofbiz/product/inventory/InventoryReserveServices.xml
Posted by Si Chen <si...@opensourcestrategies.com>.
David E. Jones wrote:
>
> Hold on a minute there.... did you actually test and find this to be a
> problem? The +/- notation is an entity engine ONLY thing and should
> never make it to the database.
>
> This patch should be reverted and if +/- are making it to the database
> instead of being replaced with an ASC/DESC by the entity engine then
> THAT bug should be fixed.
>
> This is a slippery slope and we should backup to the top before it
> gets going...
>
> -David
>
>
> On Feb 2, 2007, at 6:16 PM, sichen@apache.org wrote:
>
>> Author: sichen
>> Date: Fri Feb 2 17:16:36 2007
>> New Revision: 502824
>>
>> URL: http://svn.apache.org/viewvc?view=rev&rev=502824
>> Log:
>> Fix a pretty significant bug with sequence of inventory item
>> reservations for orders: FIFO and LIFO were reversed (I checked this)
>> and the +/- notation does not work well with PostgreSQL
>>
>> Modified:
>>
>> ofbiz/trunk/applications/product/script/org/ofbiz/product/inventory/InventoryReserveServices.xml
>>
>>
>> Modified:
>> ofbiz/trunk/applications/product/script/org/ofbiz/product/inventory/InventoryReserveServices.xml
>>
>> URL:
>> http://svn.apache.org/viewvc/ofbiz/trunk/applications/product/script/org/ofbiz/product/inventory/InventoryReserveServices.xml?view=diff&rev=502824&r1=502823&r2=502824
>>
>> ==============================================================================
>>
>> ---
>> ofbiz/trunk/applications/product/script/org/ofbiz/product/inventory/InventoryReserveServices.xml
>> (original)
>> +++
>> ofbiz/trunk/applications/product/script/org/ofbiz/product/inventory/InventoryReserveServices.xml
>> Fri Feb 2 17:16:36 2007
>> @@ -42,23 +42,26 @@
>> <entity-one entity-name="OrderHeader"
>> value-name="orderHeader"/>
>>
>> <!-- before we do the find, put together the orderBy list
>> based on which reserveOrderEnumId is specified -->
>> + <!-- FIFO=first in first out, so it should be order by
>> ASCending receive or expire date
>> + LIFO=last in first out, so it means order by DESCending
>> receive or expire date
>> + -->
>> <if-compare value="INVRO_GUNIT_COST" operator="equals"
>> field-name="reserveOrderEnumId" map-name="parameters">
>> - <set value="-unitCost" field="orderByString"/>
>> + <set value="unitCost DESC" field="orderByString"/>
>> <else>
>> <if-compare value="INVRO_LUNIT_COST" operator="equals"
>> field-name="reserveOrderEnumId" map-name="parameters">
>> - <set value="+unitCost" field="orderByString"/>
>> + <set value="unitCost ASC" field="orderByString"/>
>> <else>
>> <if-compare value="INVRO_FIFO_EXP" operator="equals"
>> field-name="reserveOrderEnumId" map-name="parameters">
>> - <set value="+expireDate" field="orderByString"/>
>> + <set value="expireDate ASC" field="orderByString"/>
>> <else>
>> <if-compare value="INVRO_LIFO_EXP"
>> operator="equals" field-name="reserveOrderEnumId" map-name="parameters">
>> - <set value="-expireDate"
>> field="orderByString"/>
>> + <set value="expireDate DESC"
>> field="orderByString"/>
>> <else>
>> <if-compare value="INVRO_LIFO_REC"
>> operator="equals" field-name="reserveOrderEnumId" map-name="parameters">
>> - <set value="+datetimeReceived"
>> field="orderByString"/>
>> + <set value="datetimeReceived DESC"
>> field="orderByString"/>
>> <else>
>> <!-- the default reserveOrderEnumId is
>> INVRO_FIFO_REC, ie FIFO based on date received -->
>> - <set value="-datetimeReceived"
>> field="orderByString"/>
>> + <set value="datetimeReceived ASC"
>> field="orderByString"/>
>> <set value="INVRO_FIFO_REC"
>> field="parameters.reserveOrderEnumId"/>
>> </else>
>> </if-compare>
>>
>>
>
David,
I worked on this with Leon, and we did test this a few times, and the
inventory reservation sequence was wrong. Previously when using the
FIFO reservation, the last item received was being reserved against
orders. It seems that "-datetimeReceived" was ordering them by
descending order of date time received, and as a result reservations
were done in the wrong sequence.
We did not realize that the + or - notation were an entity engine thing,
but please test the actual reservation of inventory before and after
this patch and let us know which behavior you feel is correct. I
realize this is a pretty basic fix to an existing feature, and I had
trouble believing that something like this could be broken, but we did
try it several times ourselves.
Si