[
https://jira.nuxeo.com/browse/NXS-804?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=104468#comment-104468
]
Anahide Tchertchian commented on NXS-804:
-----------------------------------------
finally implement solution 3 to avoid renaming multiple fields under a complex
field (would be a pain to generate again the accurate field name in other
features using the property name)
=> to sum up:
- rename type names used for complex fields (has an impact on table name, no
impact on field name)
- do not rename multiple fields under a complex field although table names are
using the field name only, and generate validation errors when collisions are
detected.
> Fix potential collisions when defining several complex types or sub fields
> with the same name
> ---------------------------------------------------------------------------------------------
>
> Key: NXS-804
> URL: https://jira.nuxeo.com/browse/NXS-804
> Project: Nuxeo Studio
> Issue Type: Bug
> Components: Schemas
> Affects Versions: 2.4
> Reporter: Anahide Tchertchian
> Assignee: Anahide Tchertchian
> Priority: Major
> Fix For: 2.4.1
>
>
> The way complex types are currently generated by Studio can lead to table
> collisions on VCS because of the way it handles storage of complex fields.
> Possible problems are:
> 1. defining the same complex type (not multi valued) with the same name in
> two distinct schemas => VCS will store all the data in the same table, which
> may not be the wanted behaviour, and will cause a conflict problem if one of
> the schema changes
> 2. defining a multi valued sub field in two distinct complex types, with the
> same name or not, in two distinct schemas or not => VCS will store all the
> data in the same table, which may not be the wanted behaviour
> 3. defining the same complex type (multi valued) with the same name in two
> distinct schemas => repository initialization will fail (see problem reported
> in NXS-781)
> Possible solutions are:
> 1. let Studio handle disambiguisation, by making sure VCS will store data in
> distinct tables in all the cases => this will cause a migration issue for
> existing persisted data
> 2. issue validation errors when a potential collision is detected by Studio
> (implementation not trivial)
> 3. a combination of both, maybe using a property on the project to chose
> whether disambiguisation should be done, or not (for compatibility)
> Ideally, this problem should be handled by VCS itself, but Studio still need
> to handle the feature correctly for a 5.4.2 version of VCS.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
_______________________________________________
ECM-tickets mailing list
[email protected]
http://lists.nuxeo.com/mailman/listinfo/ecm-tickets
