Globally unique but language specific index #316
Comments
novoj
changed the title
novoj
added a commit
that referenced
this issue
Dec 1, 2023
Currently we support `uniqueGlobally` attributes, which behave as a unique index over that attribute among all entities, regardless of the locale of the attribute, if the attribute is also `localized`. In some projects we want to use this index for URL attributes, but we only store relative URLs in the database. If the locale is bound (can be derived) to the missing part of the url - the domain/hostname - the URL will be the same for multiple locale variants and thus the globally unique constraint will be broken in this situation. We need to optionally support two `uniqueGlobally' behaviors: - **IN_ALL_LOCALES**: current behavior - **LOCALE_SPECIFIC**: new behavior where the database will only check for attribute uniqueness among attributes in the same locale. The second behavior disables the functionality of the implicit locale, which can no longer be derived from the unique attribute in the filter constraint for attributes with LOCALE_SPECIFIC uniqueness - since multiple locales can match the same content of the attribute value.
|
Implementation is done. @lukashornych can you please adapt REST / GraphQL implementations to reflect the change that unique attributes (either global or collection wide) can now be locale specific? We would need to require locale for all request on those attributes. Also please check my changes in external API libraries. |
|
The GQL and REST APIs are adapted. There is only one test that strangely doesn't pass because of default ordering of entities but I hope that after we merge dev, it will work. |
|
Only missing is now evitaLab... will work on that now. |
|
evitaLab is now implemented and commited into the evitaDB codebase as well. |
novoj
added a commit
that referenced
this issue
Dec 6, 2023
…e-specific-index #316 globaly unique but language specific index
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Currently we support
uniqueGloballyattributes, which behave as a unique index over that attribute among all entities, regardless of the locale of the attribute, if the attribute is alsolocalized. In some projects we want to use this index for URL attributes, but we only store relative URLs in the database. If the locale is bound (can be derived) to the missing part of the url - the domain/hostname - the URL will be the same for multiple locale variants and thus the globally unique constraint will be broken in this situation.We need to optionally support two `uniqueGlobally' behaviors:
The second behavior disables the functionality of the implicit locale, which can no longer be derived from the unique attribute in the filter constraint for attributes with LOCALE_SPECIFIC uniqueness - since multiple locales can match the same content of the attribute value.
The text was updated successfully, but these errors were encountered: