Regular update of stable changes from dev #364
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…cetSummaryOfReference in QueryConstraints
…Constraints, added parser tests for these new overloads
# Conflicts: # evita_functional_tests/src/test/java/io/evitadb/documentation/UserDocumentationTest.java
# Conflicts: # documentation/user/en/query/requirements/histogram.md # documentation/user/en/query/requirements/paging.md
GQL/REST hierarchy requirements specific docs
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.
In a bid to increase the semantics of the codebase, the 'MemTable' term has been refactored to 'FileOffsetIndex'. This change affects java import statements and method calls across multiple Java files in the evita_store's memtable module. The refactoring is limited to renaming and does not introduce any functional modifications. New name better reflects the nature of the data structure.
Changed the declared type of TargetIndexes to use wildcard generics in multiple classes, in order to allow for broader use. This will permit the passing in of any object that extends the base Index class, instead of limiting it to only EntityIndex. This change was necessary to allow for more flexibility and generality in the codebase, as it no longer ties this part of the code strictly to the EntityIndex class, and allows for the passing in of different types of indexes. Also added the inspection tool 'LombokGetterMayBeUsed' in Evita_DB_Defaults.xml for potential usage.
Changed the declared type of TargetIndexes to use wildcard generics in multiple classes, in order to allow for broader use. This will permit the passing in of any object that extends the base Index class, instead of limiting it to only EntityIndex. This change was necessary to allow for more flexibility and generality in the codebase, as it no longer ties this part of the code strictly to the EntityIndex class, and allows for the passing in of different types of indexes. Also added the inspection tool 'LombokGetterMayBeUsed' in Evita_DB_Defaults.xml for potential usage.
# Conflicts: # evita_functional_tests/src/test/java/io/evitadb/documentation/UserDocumentationTest.java # evita_query/src/main/java/io/evitadb/api/query/parser/grammar/EvitaQLLexer.java
New name aligns with naming in "filter by" chapters and is more comprehensible to the readers.
Former implementation allowed to create reference targeting non-existing evitaDB entity type.
…erence-targetting-non-existing-evitadb-entity-type fix(#162): add validation for managed entity references
…o recommendations, added support for C# DocumentationProfile setting
…y-within-locale attributes
This reverts commit 4a321f6.
Reworked original implementation which broke a lot of tests and I'm afraid it would break current clients as well. I think we need to postpone validation and allow multiple schemas to be defined in bulk to avoid unnecessary complexity on the client side while maintaining model consistency. Current use case: Product -> References Category category -> references products (related products specified at category level) It's a circular dependency, but it's a real use case that we need to support. The only situation to avoid the exception would be 1. create category 2. create product that references category 3. change category to reference related products This requires quite complicated setup on the client side, which now uses the `ClassAnalyzer` facility to set up the schema. So a new suggestion would be to validate the schema not in the mutation, but at the end of the updateSchema method. In `io.evitadb.core.EvitaSession#updateCatalogSchema` method the validation will be done after all mutations have been processed. This would allow to set up circular dependent updates in one go and still pass the validation.
Cleaning - two interfaces joined together.
This allows to define multiple entity schemas at once before sending them to evitaDB server.
This allows to define multiple entity schemas at once before sending them to evitaDB server.
# Conflicts: # evita_api/src/main/java/io/evitadb/api/requestResponse/schema/dto/CatalogSchema.java # evita_api/src/main/java/io/evitadb/api/requestResponse/schema/mutation/attribute/CreateGlobalAttributeSchemaMutation.java
…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
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.