Discussions
Categories
- 196.8K All Categories
- 2.2K Data
- 235 Big Data Appliance
- 1.9K Data Science
- 449.9K Databases
- 221.6K General Database Discussions
- 3.8K Java and JavaScript in the Database
- 31 Multilingual Engine
- 549 MySQL Community Space
- 478 NoSQL Database
- 7.9K Oracle Database Express Edition (XE)
- 3K ORDS, SODA & JSON in the Database
- 532 SQLcl
- 4K SQL Developer Data Modeler
- 186.9K SQL & PL/SQL
- 21.3K SQL Developer
- 295.4K Development
- 17 Developer Projects
- 138 Programming Languages
- 292.1K Development Tools
- 104 DevOps
- 3.1K QA/Testing
- 645.9K Java
- 28 Java Learning Subscription
- 37K Database Connectivity
- 154 Java Community Process
- 105 Java 25
- 22.1K Java APIs
- 138.1K Java Development Tools
- 165.3K Java EE (Java Enterprise Edition)
- 17 Java Essentials
- 158 Java 8 Questions
- 85.9K Java Programming
- 79 Java Puzzle Ball
- 65.1K New To Java
- 1.7K Training / Learning / Certification
- 13.8K Java HotSpot Virtual Machine
- 94.2K Java SE
- 13.8K Java Security
- 203 Java User Groups
- 24 JavaScript - Nashorn
- Programs
- 401 LiveLabs
- 37 Workshops
- 10.2K Software
- 6.7K Berkeley DB Family
- 3.5K JHeadstart
- 5.6K Other Languages
- 2.3K Chinese
- 171 Deutsche Oracle Community
- 1.1K Español
- 1.9K Japanese
- 230 Portuguese
ODM: Double relationshipnames when using gitHub

We are using gitHub to version-control our model.
If 2 users in two clones of the same model create a relation, it happens, that the names of the relations are identical ("Relation_nnn", nnn incremented automatically). After commit, push and merge, we have two relations (in two files, different ids) with the same name. The modeler handles this by adding "v1" for the display to one of the names. BUT it does not store this unless you change something in the relation.
The same could happen with every element, having unique names.
This inconsistency (2 identical relation-names) remains in the xml-files. As we analyse these files for further usage, we run into trouble.
Any idea, how we can avoid duplicate names?
Answers
-
Any idea, how we can avoid duplicate names?
1) better coordination in the team - split the model on subject areas and different people to work on different areas. As you pointed that could happen for any new object if there is another object with the same name and type(entity, table...) created in another branch.
2) git functionality is acting first on merge. If there is a conflict then our code is acting (local merge) in order to minimize damages. If there are no conflicts (according git) then DM cannot do anything. You can use two local clones of repository for different branches and use DM functionality for 'compare and merge models" or import of DM design. Then you can analyze reported changes and decide whether to go with Git merge or use DM import
Philip