I have a requirement to add security questions to a user account. Account Entity: Question1 (String), Question2 (String), Question3 (String), [+ other attributes] SecurityQuestion Entity: Question (string) The goal is to have 3 questions stored on the user account abject that are copied as strings to make sure the question is what the user selected. My first idea was to have 3 question attributes, as string types, on the account object, then use a drop down list for each one, but surprisingly, there’s no way to pull a list of string values from a data source for a string attribute (which I have a hard time accepting is the case for such a common basic operation). I do not want to use enums, as the users want a UI to edit the list themselves. I do not want associated objects, as I want the questions to copy over to the user’s account so that changing them in the database doesn’t alter what the user selected prior. As such, the target account question attributes must be a string type. I already thought of using a non-persistent entity associated to the account, then convert the save button to a microflow to copy the values, but I also would need to make sure the reverse also works to show the previous entries. That may require another MF to open the form and search for question objects 3 times (one search operation for each question) and then update the non-persistent object with each result, but I would think Mendix is supposed to save me time, not cause me more grief. :P ;) Any ideas? Thanks.
What problem are you trying to solve? From your description, it seems that each account has three questions. To reflect this in the domain model add a separate entity SecurityQuestion with an association to entity Account.
The denormalized version, adding three attributes to Account is possible and will work fine, but you will indeed have a hard time creating the dropdown.