Hi,
In product pricing, we can define multiple record PRIMARY KEY (product_id, product_price_type_id, product_price_purpose_id, currency_uom_id, product_store_group_id, from_date) My below scenario is at below (1 + 2 + 3 + 4 + 5 + 2Jan2014 ) and thruDate = 15Jan2014 (1 + 2 + 3 + 4 + 5 + 15Jan2014 ) and thruDate is null and i would like to return 15jan2014 pricing, and i will return 2 records. And assuming timestamp is not important in this scenario. Just only the date What is the current practice of choosing which record to retrieve ? -- Disclaimer : This E-mail is intended only for the use of the individual or entity named above and may contain information that is confidential. If you are not the intended recipients, please immediately notify us by return email and delete it from your system. Any unauthorised dissemination, distribution or copying of this email is strictly prohibited. Thank You. |
In existing code, the first item in the list is used. Most of the time,
no order is set - so the result can be unpredictable (the first item in the list will depend upon the ordering in the data source). Adrian Crum Sandglass Software www.sandglass-software.com On 5/29/2014 5:04 AM, Jen Sing Choe wrote: > Hi, > In product pricing, we can define multiple record > > PRIMARY KEY (product_id, product_price_type_id, product_price_purpose_id, > currency_uom_id, product_store_group_id, from_date) > > My below scenario is at below > > (1 + 2 + 3 + 4 + 5 + 2Jan2014 ) and thruDate = 15Jan2014 > (1 + 2 + 3 + 4 + 5 + 15Jan2014 ) and thruDate is null > > > and i would like to return 15jan2014 pricing, and i will return 2 records. > And assuming timestamp is not important in this scenario. Just only the date > > What is the current practice of choosing which record to retrieve ? > |
In reply to this post by twosolution
Hi,
In the database, the dates are stored with non-zero time. When selecting a price, you can choose to filter with a date with zero time. So the effect is you will retrieve only 1 record.
|
Even if i apply ordering, it will still create confusing especially on the
ecommerce/PO/invoice I feel a bit weird that out-of-the-box, ofbiz does not prevent over-lapping on the time-based condition. Ofbiz only prevent the from having the same start date. Is it better, if there is over-lapping time-based checking (on date without timestamp) ? On Fri, May 30, 2014 at 2:59 PM, james_sg <[hidden email]> wrote: > Hi, > > In the database, the dates are stored with non-zero time. > When selecting a price, you can choose to filter with a date with zero > time. > So the effect is you will retrieve only 1 record. > > > twosolution wrote > > Hi, > > In product pricing, we can define multiple record > > > > PRIMARY KEY (product_id, product_price_type_id, product_price_purpose_id, > > currency_uom_id, product_store_group_id, from_date) > > > > My below scenario is at below > > > > (1 + 2 + 3 + 4 + 5 + 2Jan2014 ) and thruDate = 15Jan2014 > > (1 + 2 + 3 + 4 + 5 + 15Jan2014 ) and thruDate is null > > > > > > and i would like to return 15jan2014 pricing, and i will return 2 > records. > > And assuming timestamp is not important in this scenario. Just only the > > date > > > > What is the current practice of choosing which record to retrieve ? > > > > -- > > Disclaimer : This E-mail is intended only for the use of the individual > or > > entity named above and may contain information that is confidential. If > > you > > are not the intended recipients, please immediately notify us by return > > email and delete it from your system. Any unauthorised dissemination, > > distribution or copying of this email is strictly prohibited. Thank You. > > > > > > -- > View this message in context: > http://ofbiz.135035.n4.nabble.com/Product-Pricing-multiple-time-based-record-tp4651240p4651249.html > Sent from the OFBiz - User mailing list archive at Nabble.com. > -- Disclaimer : This E-mail is intended only for the use of the individual or entity named above and may contain information that is confidential. If you are not the intended recipients, please immediately notify us by return email and delete it from your system. Any unauthorised dissemination, distribution or copying of this email is strictly prohibited. Thank You. |
Hi twosolution,
Lets turn to the 1st example given by you where all the dates have zero time. Study the following code in EntityDateFilterCondition.java. public static EntityExpr makeCondition(Timestamp moment, String fromDateName, String thruDateName) { return EntityCondition.makeCondition( EntityCondition.makeCondition( EntityCondition.makeCondition( thruDateName, EntityOperator.EQUALS, null ), EntityOperator.OR, EntityCondition.makeCondition( thruDateName, EntityOperator.GREATER_THAN, moment ) ), EntityOperator.AND, EntityCondition.makeCondition( EntityCondition.makeCondition( fromDateName, EntityOperator.EQUALS, null ), EntityOperator.OR, EntityCondition.makeCondition( fromDateName, EntityOperator.LESS_THAN_EQUAL_TO, moment ) ) ); } Ofbiz will only return 1 record in your given scenario when you get a price for the date on 15th Jan.
|
Administrator
|
In reply to this post by twosolution
Seems that I forgot this one https://issues.apache.org/jira/browse/OFBIZ-3161
Too much things on my plate :/ I will try to review... Jacques Le 31/05/2014 01:44, Jen Sing Choe a écrit : > Even if i apply ordering, it will still create confusing especially on the > ecommerce/PO/invoice > I feel a bit weird that out-of-the-box, ofbiz does not prevent over-lapping > on the time-based condition. > Ofbiz only prevent the from having the same start date. > Is it better, if there is over-lapping time-based checking (on date without > timestamp) ? > > > > > On Fri, May 30, 2014 at 2:59 PM, james_sg <[hidden email]> wrote: > >> Hi, >> >> In the database, the dates are stored with non-zero time. >> When selecting a price, you can choose to filter with a date with zero >> time. >> So the effect is you will retrieve only 1 record. >> >> >> twosolution wrote >>> Hi, >>> In product pricing, we can define multiple record >>> >>> PRIMARY KEY (product_id, product_price_type_id, product_price_purpose_id, >>> currency_uom_id, product_store_group_id, from_date) >>> >>> My below scenario is at below >>> >>> (1 + 2 + 3 + 4 + 5 + 2Jan2014 ) and thruDate = 15Jan2014 >>> (1 + 2 + 3 + 4 + 5 + 15Jan2014 ) and thruDate is null >>> >>> >>> and i would like to return 15jan2014 pricing, and i will return 2 >> records. >>> And assuming timestamp is not important in this scenario. Just only the >>> date >>> >>> What is the current practice of choosing which record to retrieve ? >>> >>> -- >>> Disclaimer : This E-mail is intended only for the use of the individual >> or >>> entity named above and may contain information that is confidential. If >>> you >>> are not the intended recipients, please immediately notify us by return >>> email and delete it from your system. Any unauthorised dissemination, >>> distribution or copying of this email is strictly prohibited. Thank You. >> >> >> >> >> -- >> View this message in context: >> http://ofbiz.135035.n4.nabble.com/Product-Pricing-multiple-time-based-record-tp4651240p4651249.html >> Sent from the OFBiz - User mailing list archive at Nabble.com. >> -- |
Hi Jacques,
Just to mention that in the example given by twosolution, the database records are correct. However he has some misunderstanding on how 'thru date' in OFBiz meant.
|
Administrator
|
Yes got it thanks ;)
Still this trivial issue pending... But anyway who cares... Jacques Le 31/05/2014 16:49, james_sg a écrit : > Hi Jacques, > > Just to mention that in the example given by twosolution, the database > records are correct. However he has some misunderstanding on how 'thru date' > in OFBiz meant. > > > Jacques Le Roux wrote >> Seems that I forgot this one >> https://issues.apache.org/jira/browse/OFBIZ-3161 >> >> Too much things on my plate :/ I will try to review... >> >> Jacques >> >> Le 31/05/2014 01:44, Jen Sing Choe a écrit : >>> Even if i apply ordering, it will still create confusing especially on >>> the >>> ecommerce/PO/invoice >>> I feel a bit weird that out-of-the-box, ofbiz does not prevent >>> over-lapping >>> on the time-based condition. >>> Ofbiz only prevent the from having the same start date. >>> Is it better, if there is over-lapping time-based checking (on date >>> without >>> timestamp) ? >>> >>> >>> >>> >>> On Fri, May 30, 2014 at 2:59 PM, james_sg < >> snowmedal@ >> > wrote: >>>> Hi, >>>> >>>> In the database, the dates are stored with non-zero time. >>>> When selecting a price, you can choose to filter with a date with zero >>>> time. >>>> So the effect is you will retrieve only 1 record. >>>> >>>> >>>> twosolution wrote >>>>> Hi, >>>>> In product pricing, we can define multiple record >>>>> >>>>> PRIMARY KEY (product_id, product_price_type_id, >>>>> product_price_purpose_id, >>>>> currency_uom_id, product_store_group_id, from_date) >>>>> >>>>> My below scenario is at below >>>>> >>>>> (1 + 2 + 3 + 4 + 5 + 2Jan2014 ) and thruDate = 15Jan2014 >>>>> (1 + 2 + 3 + 4 + 5 + 15Jan2014 ) and thruDate is null >>>>> >>>>> >>>>> and i would like to return 15jan2014 pricing, and i will return 2 >>>> records. >>>>> And assuming timestamp is not important in this scenario. Just only the >>>>> date >>>>> >>>>> What is the current practice of choosing which record to retrieve ? >>>>> >>>>> -- >>>>> Disclaimer : This E-mail is intended only for the use of the individual >>>> or >>>>> entity named above and may contain information that is confidential. If >>>>> you >>>>> are not the intended recipients, please immediately notify us by return >>>>> email and delete it from your system. Any unauthorised dissemination, >>>>> distribution or copying of this email is strictly prohibited. Thank >>>>> You. >>>> >>>> >>>> >>>> -- >>>> View this message in context: >>>> http://ofbiz.135035.n4.nabble.com/Product-Pricing-multiple-time-based-record-tp4651240p4651249.html >>>> Sent from the OFBiz - User mailing list archive at Nabble.com. >>>> >> -- > > > > > -- > View this message in context: http://ofbiz.135035.n4.nabble.com/Product-Pricing-multiple-time-based-record-tp4651240p4651296.html > Sent from the OFBiz - User mailing list archive at Nabble.com. > > -- |
Free forum by Nabble | Edit this page |