As thought at the beginning of the specifications for the type generator, we should give the possibility to give several types from reference selection for a reference field.
The type field should not contain a single value (TypeID), but rather a list of possible type IDs.
For compatibility reasons, I would suggest that these are interpreted according to the particular storage type. So we would not have to change the database structure at this point.
We also need to handle references to multiple types in Exportd/DocAPI.
Yes, we would then have to check at which points the implementation could break the current interfaces. Sergei and I had a brief look at it. As I said, the way it looks, no database migration needs to be done. But let's move the topic to a later sprint.
tagged that with “Refinement“. Lets talk about that issue tomorrow and decide, if we plan that for the next sprint.
Started with testing of this functionality. When adding a new reference field to an existing type and choose a type for this reference, I got the following exception:
I see a lot of issues with that story. Do you have time to do some enhanced testing of that functionality? If you found anything, please open a bug
Changed the Jira Workflow from DATAGERRY -> DATAGERRY 2.0