Best practice for modeling issue

0
Hi community, I have a modeling issue, that I cannot solve. Suggestions would be great! Setting: I have the following entities   In words: there are products, each product is associated with one productType. Each productType can have several DiscountLevels. Each customer shall be associated with 1 DiscountLevel per ProductType. To lin customer with DiscountLevel, I use a reference set selector. To ensure the condition "only one discountLevel per producttype" I use an onChange microflow of this reference selector. In the microflow, I receive all productType. This list is used as Iterator in a Loop. For each Loop cycle, I get the discountLevels for the producttype and customer (Output is as list). Then I Count this list, if > 1 then do not commit. However, this solution does not work. since the newly linked discountlevel is not committed yet and thus does not Show up in the list. Solution Options / questions How can I ensure that only one DiscountLevel per producttype is associated with a customer? Is there a way to get the uncommitted associations? How can I get the associations between a specific customer and discountlevel (many to many relation)? I have checked out the "objectIsNew" Java Action from the CommunityCommons Lib, however, this is to find uncommitted objects, not associations  
asked
2 answers
5

Tim,

It seems to me you need an additional entity that will have associations to Customer, ProductType and Discount.  This will enable you to keep track of what discount an individual customer should have on a certain product type.  Using this structure, you can ensure that each customer has only one discount for a given product type by retrieving from that entity and making sure there is only one object for each combo of customer / product type / discount.  Also, you'll be able to easily retrieve the correct discount for a customer / product type by retrieving from this entity.

Hope that helps,

Mike

answered
0

Hey Tim

To expand upon the suggestions of Mike, it would end up looking something like this, where your DiscountLevel entity represents a fixed list of possible discount levels (that you can adjust in the data without resorting to code changes). The CustomerDiscountLevel entityrepresents a a single instance of a discount for a given customer on a specific product. All associations can be done via reference selectors.

  • XPath is your friend. You can retrieve from the database all CustomerDiscountLevels that have associations to the given ProductType and Customer. If you simply do this as part of your entity creation process (or on an "on change" event on the reference selector for Customer and/or ProductType).
  • Associations are part of an object. Looking for uncommitted associations is like looking for uncommitted changes to an Object's attributes. In short, no. The slightly longer answer is you shouldn't have to. Have better control over where you create and commit. When in doubt, always commit. Don't leave uncommitted changes hanging around in your system.
  • Again, a simple XPath query will help you. Since it is a bit of a pain to find proper info on Mendix XPath I will leave the query here for you as an example. This will get you all CustomerDiscountLevels for a given DiscountLevel and Customer.
    [Module.CustomerDiscountLevel_Customer = $Customer
    and Module.CustomerDiscountLevel_DiscountLevelConfig = $DiscountLevelConfig]
  • Yeah, that won't help you I am afraid. That is specifically useful only when entire objects have not yet been committed, not when they are committed but have been changed since their commit. As far as I know, at least.
answered