Re: Product features and user-provided data
On 8/15/16 13:03, Taher Alkhateeb wrote: values do not change (the description remains the same and everything else). So the logic around receiving input from users, validating it, storing it, and fetching it later adds complexity that does not exist with system-defined values. Taher, Thank you for the response, this helped me get things in the ofbiz way a little better. We're looking at a ProductQuestion entity similar to ProductFeature but using our existing EAV structure to facilitate the requirements and validation and then a linked entity from OrderItem to store the results of those answers. Cheers, Brian
Re: Product features and user-provided data
On 8/14/16 01:07, Taher Alkhateeb wrote: I think perhaps what you are seeking is not related to the product data model, instead, it is related to order. Now, in your case this might be a bit too custom for your needs. I'm not sure but I would suggest to store such values in OrderItemAttribute where you define a custom attribute maybe with a key called CUSTOM_EMBROIDER for example. Then you build your solution around that attribute key. Thanks Taher, that's a good direction to consider. The reason that I looked at Product Features is because my users conceptually consider system-defined and user-defined options for a product as roughly equivalent and they are related at the order line item level. You could imagine: Product: Engagement Ring System-defined Product Feature Types where product features are enumerated: Size (finger sizes) Material (gold, silver, plat) Stone type (diamond, opal, ruby) User-defined "Product Feature Types" where the product features are provided by the user: Engraving text (text, limit of 30 characters, engraved on the ring) Date of wedding (date field, used for customer service to send a wedding card) Name of partner (text, limit of 10 characters, printed onto a certificate of authenticity) Total amount you want to spend (money/decimal field, choose a stone quality/size which stays within budget) This is just an example but the idea is that my admins may want to collect ad-hoc data from the customer. They want to see it with the line item that has been purchased, include it in receipts, print it in reports, etc. Today we do this using EAV since our SaaS system can't define it in advance for all customers. Looking at OrderItemAttribute, it looks like a candidate, but I don't see where in the model you define what the attributes are? E.g., where would I define the label "Date of wedding"? What if I wanted to specify it should be a date? What if I wanted to define it as required or optional? If those are all things that need to be added, it sounds like duplicating much of the ProductFeature supporting entities? Can ProductFeatures and OrderItem be intelligently extended to handle both system-defined and user-defined values? Brian
Product features and user-provided data
A model question from the OfBizDatamodelBook PDFs and https://cwiki.apache.org/confluence/display/OFBENDUSER/Product+Features I believe I understand I can have a ProductFeatureType of "Brand" with ProductFeatures of Hanes, American Apparel and Lacoste that could be related to my Product. What if I have user-provided data for my product? For example, I have a "Name to embroider on shirt" where I want to collect an arbitrary value from the buyer? Once that's presented to the user in the purchase process as something like a text input field, where would OfBiz store that value for a particular Order Item? Brian
Re: Theory of Composite keys with From date vs Thru date?
Thanks Pierre and Taher for your responses, a couple of follow-ups below: On 8/9/16 01:44, Pierre Smits wrote: The one thing is related to creating a unique key based on the fromDate in combination with the other elements of the primary key. As an example, have a look at the following (excerpt) of the entity ProductCategoryMember : ... As you can see from above examples, the thruDate is not required to determine record uniqueness. It only determines applicability in time. I'm under the belief that no entity can have more than one active version - e.g., the from/thru dates must not overlap. Is that correct? I was thinking that your current entities would always have a null/magic number/infinity thruDate so using thruDate instead in the index would be more efficient for queries but clearly you could put a thruDate on your active entity so that doesn't hold up. Thanks for clearing that up. Does selecting the active version of an entity essentially always includes a where clause checking that the current date is between the from/thru date? E.g.: SELECT * FROM productCategory WHERE productCategoryId = 100 AND now() BETWEEN fromDate AND thruDate Do these entity tables have separate indices on fromDate/thruDate for query performance? Brian
Theory of Composite keys with From date vs Thru date?
I'm a big fan of Silverston and his UDM books and have been studying OfBiz extensively. I was wondering if anyone can explain why his entities with from/thru date use the from date instead of the thru date in the composite keys? It seems like you would want to enforce only one version is ever active at a time by uniquely indexing the thru date as null (or a magic end date, or infinity in Postgres). I'd be very appreciative of any theory explanations on the use of from date instead of thru date? Brian
