V3 naksha 48 custom indices by Marcin-Here · Pull Request #674 · heremaps/naksha

Marcin-Here · 2026-10-08T07:09:37Z

No description provided.

- customIndexMapping model (lib-core models) and CustomIndexMappingCompiler that validates mappings and expands them into cmNN members / ciNN indices - CollectionIndexPolicy.toNativeCollection: shared preparation for lazy creation, collection writes and extensions; unmapped definitions unchanged - DefaultStorageHandler: mapped lazy creation, Handler collection precedence for mapped collection writes, property search translated to member queries - Mapped collections are created (or verified) when a Space or Handler is saved; unmapped collections stay lazy - Spaces must not define mappings when a Handler defines the collection - PgCollection.verifyNewHeadState rejects schema changes of existing collections with CONFLICT - QueryParameterDecoder: fix parsing of unquoted false Signed-off-by: Marcin-Here <ext-marcin.grabowski@here.com>

- Create or verify a Handler's mapped collection after authorization and validation, for every DefaultStorageHandler write (incl. UPSERT and batches); existing collections are verified when the mapping is removed or creation is disabled - Check hidden Space mappings before the Space collection is written - Only the built-in DefaultStorageHandler defines a collection for provisioning and validation - verifyNewHeadState compares member JSON paths, not only columns - Reject mappings overlapping any existing member path - Reject mapped Space writes that are not a single create or update Signed-off-by: Marcin-Here <ext-marcin.grabowski@here.com>

…ped paths - Space create and update check write access before the collection is written; AuthorizationEventHandler exposes the existing check - verifyNewHeadState compares member paths as typed segments - Document that changing hubSlimIndices requires a migration Signed-off-by: Marcin-Here <ext-marcin.grabowski@here.com>

…ed by the Hub) Signed-off-by: Marcin-Here <ext-marcin.grabowski@here.com>

…ings Handler collections are already created or verified when the Handler is saved. Signed-off-by: Marcin-Here <ext-marcin.grabowski@here.com>

Signed-off-by: Marcin-Here <ext-marcin.grabowski@here.com>

Keep the existing v3 handler existence check unchanged. This reverts commit b30d485. Signed-off-by: Marcin-Here <ext-marcin.grabowski@here.com>

… deprecated property query Signed-off-by: Marcin-Here <ext-marcin.grabowski@here.com>

…Util.box Signed-off-by: Marcin-Here <ext-marcin.grabowski@here.com>

…le field Signed-off-by: Marcin-Here <ext-marcin.grabowski@here.com>

…asses Handler saves create or verify the mapped collections returned by DefaultStorageHandler.configuredCollections(). Subclasses with other collection properties (e.g. HeteroStorageHandler) override it. Handlers are created with a placeholder Space, because a Handler save has no Space. Signed-off-by: Marcin-Here <ext-marcin.grabowski@here.com>

Signed-off-by: Marcin-Here <ext-marcin.grabowski@here.com>

hirenkp2000 · 2026-10-12T11:16:51Z

      return executeDeleteSpace(writeRequest);
    } else if (isUpdateSpaceRequest(writeRequest, spaceId)) {
      return executeUpdateSpace(writeRequest);
+    } else if (isCreateSpaceRequest(writeRequest, spaceId)) {


We do not create collection upfront, when a space is created. It is possible that the one who creates a Space does not have Collection creation permission.
The Collection creation happens in a reactive manner when collection is not found while performing the Read/Write Features request.

I would suggest we retain the same approach, unless I miss something here.

hirenkp2000 · 2026-10-12T11:19:30Z

    final Space space = ((Space) updateSpaceEntryReq.getWrites().get(0).getFeature());
    final SpaceProperties spaceProperties = space.getProperties();
+    // The collection is written before the Space, so the Space write must be authorized first.
+    final ErrorResponse forbidden = new AuthorizationEventHandler(nakshaHub).checkWriteAccess();


This approach is not able to check whether it has write request against a specific SpaceID or specific CollectionId or not. It only checks whether a broader "write" permission is allowed or not. And this will already happen as part of executeSingleCollectionWrite -> executeWriteToCustomSpaces.

So, I see this Auth check redundant. Let me know, if I miss something.

hirenkp2000 · 2026-10-12T11:48:17Z

+  }
+
+  private static @Nullable CustomIndexMappingList mappingList(NakshaCollection definition) {
+    Object raw = definition.getRaw("customIndexMapping");


To get benefit of type-safety, it is better to define "customIndexMapping" data-type as part of NakshaCollection

hirenkp2000 · 2026-10-12T12:23:01Z

We only need to validate during Update EventHandler, that customIndexMapping has not changed in new EventHandler Properties

hirenkp2000 · 2026-10-12T12:23:17Z

We only need to validate during Update Space, that customIndexMapping has not changed in new Space Properties

hirenkp2000 · 2026-10-12T12:56:41Z

+    MemberType type = member.getDataType();
+    AnyOp op = query.getOp();
+    // Boolean REST predicates encode their value in the operation, not query.value.
+    if (MemberType.BOOLEAN.equals(type)) {


can we use some mechanism here, which should give me a warning or error in future, if some newly introduced MemberType is forgotten to be covered here?

gunplar · 2026-10-12T13:31:54Z

+        path: JsonPath = JsonPath("properties", "score"),
+        indexName: String = "score_idx"
+    ) = NakshaCollection(collectionId, catalog.id).apply {
+        members = MemberList(Member("score", type, path))


Function name is rather "inhuman" ;) And moving member name to input param with default would make it more consistent with the other inputs.

xeus2001

From lib-psql side no concerns.

Signed-off-by: Marcin-Here <ext-marcin.grabowski@here.com>

github-actions · 2026-10-14T07:14:52Z

Code Coverage

Overall Project	60.98% `-0.02%`	🍏
Files changed	94.3%	🍏

File	Coverage
CustomIndexMappingList.kt	100%	🍏
IntHandlerForSpaces.java	98.44% `-1.56%`	🍏
CustomIndexMapping.kt	92.98% `-7.02%`	🍏
IntHandlerForEventHandlerConfigs.java	86.67%	🍏
DefaultStorageHandler.java	83.03%	🍏
IntValidationUtil.java	82.58% `-12.88%`	🍏
PgCollection.kt	81.74% `-0.39%`	🍏
NakshaCollection.kt	66.73% `-0.18%`	🍏

Signed-off-by: Marcin-Here <ext-marcin.grabowski@here.com>

github-actions · 2026-10-14T13:47:00Z

Code Coverage

Overall Project	60.55% `-0.06%`	🍏
Files changed	83.24%	🍏

File	Coverage
IntHandlerForSpaces.java	98.43% `-1.57%`	🍏
IntHandlerForEventHandlerConfigs.java	86.67%	🍏
DefaultStorageHandler.java	83.03%	🍏
IntValidationUtil.java	82.58% `-12.88%`	🍏
PgCollection.kt	81.74% `-0.39%`	🍏
NakshaCollection.kt	65.91% `-1%`	🍏
CustomIndexMapping.kt	43.86% `-56.14%`	🍏
CustomIndexMappingList.kt	19.23% `-80.77%`	🍏

hirenkp2000 · 2026-10-16T10:15:26Z

-      collectionForCreation.setId(operationData.getCollectionId());
-      collectionForCreation.setCatalogId(operationData.getMapId());
-      CollectionIndexPolicy.normalizeForHubCreation(collectionForCreation);
+      final NakshaCollection collectionForCreation = CollectionIndexPolicy.toNativeCollection(


What if we set members and indices as part of NakshaCollection instantiation itself?
That way, we will ALWAYS have members and indices available as part of NakshaCollection, irrespective of whether it is fetched from Storage or accepted in the input request.
And so, we don't have to call toNativeCollection from anywhere. Also, Extensions where NakshaCollection is referred, that should also automatically get benefit of having members and indices already available, without them having to explicitly invoke toNativeCollection (which most likely be missed).

Do you think of a specific challenge to talk about? OR I miss something?

why not in NakshaCollections
NakshaCollection is Proxy over PlatformObject
So it's instantiation goes through:

Configs arrive as plain maps. A NakshaCollection only exists once someone asks for it:

'space.getProperties().getCollection() -> JvmBoxingUtil.box(rawMap, NakshaCollection.class) -> Platform.proxy(rawMap, NakshaCollection::class) proxy = NakshaCollection(); // no-arg constructor, no data yet proxy.bind(rawMap, symbol); // customIndexMapping becomes visible only here'

The constructor runs before any data is attached, so it can't expand anything. The proxy is also cached on the raw map, so every reader shares the same instance and the same map.

Other approaches could be exapanding through bind() or lazy getter:

Problem: It writes into the config. Expanding on first access stores cmNN/ciNN into the raw map of the Space/Handler.
So for example the admin validator reads the collection before the Space is saved, so the generated members would be persisted with the config and returned by GET /hub/spaces/{id}.

So instead of

'{ "id": "roads", "properties": { "collection": { "id": "roads_data", "customIndexMapping": [ { "jsonPath": ["properties","score"], "dataType": "int32" } ] } } }'

We would save: '

"collection": { "id": "roads_data", "customIndexMapping": [ { "jsonPath": ["properties","score"], "dataType": "int32" } ], "members": [ ...XYZ default members (useMembers() seeds XyzMembers.ALL)..., { "name": "cm01", "dataType": "int32", "path": ["properties","score"] } ], "indices": [ { "name": "tags", ... }, { "name": "geo", ... }, { "name": "fn_nv", ... }, { "name": "ci01", "on": ["cm01"] } ] }

Next problem that indices being null on NakshaCollection creation means "use the defaults" ('XyzIndices.all) in 'PgCollection'
also that is how we deciding to add hubSlim indices.

hirenkp2000 · 2026-10-16T10:22:54Z

+
+  public static @Nullable ReadFeatures adapt(
+      ReadFeatures request, NakshaCollection schema, NakshaCollection configured) {
+    // Member queries describe single HEAD states; history reads (e.g. the activity log) stay on the legacy path.


I would like to understand what could be the logical reason to skip custom index for historical queries?

once agreed, then we should also put reason as a comment for future reference

The reason was to preserve legacy behavior.
Example: we would have v1- score:51, v2 score: 10, v3(head) score: 10
Query: p.score=51 setVersions(2)
In legacy behavior with PropertyFilter
we would UNION HISTORY and HEAD and return 2 latest versions (v2,v3) and after that we would filter in memory
and in this case we would get empty result.
In member query the condition is part on WHERE in both tables, so we would get v1.

But if we agree that property queries on custom members should follow native member-query semantics,
we can remove the history and version-count guards. The request.getQueryMembers() != null guard stays, because an existing member query needs no translation.

hirenkp2000 · 2026-10-19T05:49:52Z

+    }
+    final NakshaCollection schema = CollectionIndexPolicy.toNativeCollection(
+        configured, operationData.getCollectionId(), operationData.getMapId());
+    final ReadFeatures translated = PropertyMemberQueryTranslator.adapt(readFeatures, schema, configured);


It is not clear why we need to pass two objects schema and configured. Pls relook into simplifying this by passing only one, as in reality we will have only one collection version to work against.

Agreed simplified to one.

hirenkp2000 · 2026-10-19T06:25:47Z

+    JsonPath path = query.getProperty().getPath();
+    CustomIndexMapping mapping = mappingFor(path, configured);
+    if (mapping == null) return null;
+    Member member = CustomIndexMappingCompiler.memberForPath(schema, mapping.getJsonPath());


It is confusing, why we are searching for mapping here using mappingFor function. Isn't querying for member directly using memberForPath sufficient? Or we will miss some situation?

It was needed when we had 2 collection objects, after our simplification is no longer needed.

hirenkp2000 · 2026-10-19T06:26:37Z

+    if (member == null) return null;
+    MemberType type = member.getDataType();
+    if (!TRANSLATED_TYPES.contains(type) && !LEGACY_ONLY_TYPES.contains(type)) {
+      logger.warn("Member type {} of {} is not supported by PropertyMemberQueryTranslator, using the legacy path", type, member.getName());


also put a comment, what will be possibly impact of this warning.

We can continue with this warning. But impact is higher, because consumer may get negative impression about member support due to possibly slower responses.

It is important to validate during Space / Handler Create/Update operation, to validate that only supported member datatypes are in use.

hirenkp2000 · 2026-10-19T06:45:56Z

+    if (collection == null || collection.getCustomIndexMapping() == null) {
+      return SUCCESSFUL_VALIDATION;
+    }
+    ReadFeatures getEventHandlersRequest =


We agreed not to tie space validation logic with handler and storage instantiation for now, to avoid config v/s runtime dependency. I would like to understand reasoning if we choose to continue with it.

hirenkp2000 · 2026-10-19T06:49:41Z

+   * @throws NakshaException with {@link NakshaError#CONFLICT}, if the existing collection does not match.
+   */
+  public static void requireMatching(NakshaCollection stored, NakshaCollection definition) {
+    final NakshaCollection expected = expand(definition.copy(true));


As I put comment somewhere else, try to see, if we can avoid creating copy of collection everytime, as I think all the required information should already be available in the given collection definition itself.

hirenkp2000 · 2026-10-19T06:56:28Z

+    final NakshaCollection expected = expand(definition.copy(true));
+    for (CustomIndexMapping mapping : validatedMappings(definition)) {
+      final Member member = memberForPath(expected, mapping.getJsonPath());
+      final boolean indexed = MemberType.BOOLEAN.equals(member.getDataType()) || isIndexed(stored, member.getName());


I believe we can simplify this by only comparing the member definitions, without having to check presence of index. This is again to differentiate between config change v/s runtime behaviour change. If we miss something here, I would like to understand.

No longer needed as we validate customIndexMapping not Collection itself.

Signed-off-by: Marcin-Here <ext-marcin.grabowski@here.com>

github-actions · 2026-10-20T18:25:39Z

Code Coverage

Overall Project	60.55% `-0.05%`	🍏
Files changed	85.23%	🍏

File	Coverage
IntHandlerForSpaces.java	100%	🍏
AdminFeatureEventHandler.java	96.04% `-0.99%`	🍏
IntValidationUtil.java	89.8% `-6.12%`	🍏
IntHandlerForEventHandlerConfigs.java	86.83%	🍏
DefaultStorageHandler.java	82.76%	🍏
PgCollection.kt	81.74% `-0.39%`	🍏
NHSpaceStorageWriter.java	78.45%	🍏
NakshaCollection.kt	65.91% `-1%`	🍏
CustomIndexMapping.kt	43.86% `-56.14%`	🍏
CustomIndexMappingList.kt	19.23% `-80.77%`	🍏

hirenkp2000 · 2026-10-21T10:39:33Z

+   * Translates a property search on custom index mappings into member queries, so that the storage can use the
+   * generated indices. Returns the original request, when the collection has no mappings or the query can't be translated.
+   */
+  private @NotNull ReadFeatures translatePropertyQuery(final @NotNull OperationData operationData) {


Ensure this translate function is generic enough so that it can be moved to lib-psql level at one point, so that we don't have to do this for every handler directly using lib-psql storage.

So, may be, it should take NakshaCollection and ReadRequest as input and it should return translated ReadRequest as outcome.

This will already benefit reusability in HeterogeneousStorageHandler

hirenkp2000 · 2026-10-21T10:49:28Z

-            collectionFromRequest.setId(collectionId);
-            collectionFromRequest.setCatalogId(mapId);
-            CollectionIndexPolicy.normalizeForHubCreation(collectionFromRequest);
+            write.setFeature(CollectionIndexPolicy.toNativeCollection(collectionFromRequest, collectionId, mapId));


If we ensure members and indices are always populated whenever NakshaCollection object is created (either during JSON parsing OR while reading from Storage), then we will be able to avoid writing this custom wrapper logic in all the handlers directly using lib-psql storage.

Custom members and indices creation moved to NakshaCollection

hirenkp2000 · 2026-10-21T11:09:17Z

+  public static @Nullable ReadFeatures adapt(ReadFeatures request, NakshaCollection configured) {
+    if (request.getQueryMembers() != null) return null;
+    // History windows (versions > 1) are applied after WHERE, translating would select different versions.
+    if (request.getQueryHistory() || request.getVersions() != 1) return null;


Recheck and allow request on history to be translated from prop-search to member-based query

hirenkp2000 · 2026-10-21T11:11:53Z

+    IPropertyQuery expression = request.getQuery().getProperties();
+    if (expression == null) return null;
+    // All or nothing: one untranslatable predicate keeps the whole request on the legacy path.
+    Op propertyOp = translate(expression, CustomIndexMappingCompiler.generatedMembers(configured));


At the end, we may not need to call generatedMembers here and simply pass the input collection as is

hirenkp2000 · 2026-10-21T11:16:48Z

+    if (query instanceof PAnd) return translateChildren((PAnd) query, schema, configured, true);
+    if (query instanceof POr) {
+      // REST sends "cs={...}" as the object OR the object wrapped into an array, for a tag-map only the object fits.
+      PQuery object = objectContainment((POr) query);


Clarified.

Open for rechecking.

hirenkp2000 · 2026-10-21T11:24:46Z

+    if (member == null) return null;
+    MemberType type = member.getDataType();
+    if (!TRANSLATED_TYPES.contains(type) && !LEGACY_ONLY_TYPES.contains(type)) {
+      logger.warn("Member type {} of {} is not supported by PropertyMemberQueryTranslator, using the legacy path", type, member.getName());


We can continue with this warning. But impact is higher, because consumer may get negative impression about member support due to possibly slower responses.

It is important to validate during Space / Handler Create/Update operation, to validate that only supported member datatypes are in use.

hirenkp2000 · 2026-10-21T11:25:33Z

+   * definition is normalized in place, as before. With mappings, a copy is returned that holds the generated members
+   * and indices, but not the mapping itself, so the configuration stays unchanged.
+   */
+  public static @NotNull NakshaCollection toNativeCollection(


Remove, if this function remains unused at the end

…from NakshaCollection.kt Signed-off-by: Marcin-Here <ext-marcin.grabowski@here.com>

github-actions · 2026-10-23T09:10:29Z

Code Coverage

Overall Project	60.69% `-0.16%`	🍏
Files changed	84.14%	🍏

File	Coverage
XyzIndices.kt	100%	🍏
IntHandlerForSpaces.java	100%	🍏
AdminFeatureEventHandler.java	96.04% `-0.99%`	🍏
IntValidationUtil.java	89.8% `-6.12%`	🍏
IntHandlerForEventHandlerConfigs.java	86.83%	🍏
DefaultStorageHandler.java	82.84%	🍏
PgCollection.kt	81.74% `-0.39%`	🍏
NHSpaceStorageWriter.java	78.45%	🍏
CustomIndexMappings.kt	77.99% `-22.01%`	🍏
NakshaCollection.kt	70.82% `-1.6%`	🍏
CustomIndexMapping.kt	43.86% `-56.14%`	🍏
CustomIndexMappingList.kt	19.23% `-80.77%`	🍏

hirenkp2000 · 2026-10-26T07:14:09Z

+            for (i in 0 until mappings.size) {
+                val field = "customIndexMapping[$i]"
+                val mapping = mappings[i] ?: throw invalid(field, "must not be null")
+                for (key in mapping.keys) {


Can we safely remove this check without any logical impact? Ideally, having additional field in an object should not cause rejection. It can be ignored instead (as unknown property).
Unless you think of some other reason, that suggests we should continue with it?

hirenkp2000 · 2026-10-26T07:28:32Z

+            if (indices.none { it?.name == indexName }) indices.add(Index(indexName, member.name))
+        }
+        appliedMappings = rawMappings
+        appliedMembers = rawMembers()?.platformObject()


If we are only interested in knowing whether mapping has been already applied or not, don't we just need one single flag? I don't see benefit of having appliedMembers and appliedIndices as well. Do I miss something?

moved and use same solution as was before in useMembers

hirenkp2000 · 2026-10-26T07:43:25Z

+        val generated = CustomIndexMappings.generatedMembers(this)
+        var members = rawMembers()
+        if (members == null) {
+            members = MemberList(XyzMembers.ALL)


As the standard list of members is fixed and static, I see it as an unwanted memory overhead if we add standard members in the list of members of each NakshaCollection.

Or perhaps there is a reason, that I miss?

moved and use same solution as was before in useMembers

hirenkp2000 · 2026-10-26T09:29:07Z

    if (expression == null) return null;
    // All or nothing: one untranslatable predicate keeps the whole request on the legacy path.
-    Op propertyOp = translate(expression, CustomIndexMappingCompiler.generatedMembers(configured));
+    Op propertyOp = translate(expression, collection.useMembers());


It is confusing for me to understand purpose and differentiation between useMembers against getMembers.
Is useMembers supposed to return only the list of Standard members OR a combined list of Standard + Custom members?

Somehow, I think there is duplicate code between the two:

If it is supposed to return the combined list, then getMembers is already doing the job. In that case useMembers perhaps become obsolete?

If it is supposed to return only the standard member, then I think that is already available as XyzMembers.ALL. So, still useMembers seem redundant to me.

Need to discuss this part further, depending on how you see?

Changed as discussed.

…embers. Signed-off-by: Marcin-Here <ext-marcin.grabowski@here.com>

github-actions · 2026-10-26T15:45:53Z

Code Coverage

Overall Project	60.67% `-0.15%`	🍏
Files changed	83.24%	🍏

File	Coverage
XyzIndices.kt	100%	🍏
IntHandlerForSpaces.java	100%	🍏
AdminFeatureEventHandler.java	96.04% `-0.99%`	🍏
IntValidationUtil.java	89.8% `-6.12%`	🍏
IntHandlerForEventHandlerConfigs.java	86.83%	🍏
DefaultStorageHandler.java	82.84%	🍏
PgCollection.kt	81.74% `-0.39%`	🍏
NHSpaceStorageWriter.java	78.45%	🍏
CustomIndexMappings.kt	78.2% `-21.8%`	🍏
NakshaCollection.kt	68.57% `-1.24%`	🍏
CustomIndexMapping.kt	43.86% `-56.14%`	🍏
CustomIndexMappingList.kt	19.23% `-80.77%`	🍏

Signed-off-by: Marcin-Here <ext-marcin.grabowski@here.com>

github-actions · 2026-10-27T08:22:15Z

Code Coverage

Overall Project	60.69% `-0.15%`	🍏
Files changed	83.24%	🍏

File	Coverage
XyzIndices.kt	100%	🍏
IntHandlerForSpaces.java	100%	🍏
AdminFeatureEventHandler.java	96.04% `-0.99%`	🍏
IntValidationUtil.java	89.8% `-6.12%`	🍏
IntHandlerForEventHandlerConfigs.java	86.83%	🍏
DefaultStorageHandler.java	82.84%	🍏
PgCollection.kt	81.74% `-0.39%`	🍏
NHSpaceStorageWriter.java	78.45%	🍏
CustomIndexMappingUtil.kt	78.2% `-21.8%`	🍏
NakshaCollection.kt	68.57% `-1.24%`	🍏
CustomIndexMapping.kt	43.86% `-56.14%`	🍏
CustomIndexMappingList.kt	19.23% `-80.77%`	🍏

Marcin-Here added 11 commits October 6, 2026 08:11

CASL-1962: drop rejection of mapped Space batch/UPSERT writes (not us…

a598227

…ed by the Hub) Signed-off-by: Marcin-Here <ext-marcin.grabowski@here.com>

CASL-1962: read Space handlers only for Spaces with custom index mapp…

47aebb1

…ings Handler collections are already created or verified when the Handler is saved. Signed-off-by: Marcin-Here <ext-marcin.grabowski@here.com>

CASL-1962: read Space handlers once in IntHandlerForSpaces

5e15f67

Signed-off-by: Marcin-Here <ext-marcin.grabowski@here.com>

Revert "CASL-1962: read Space handlers once in IntHandlerForSpaces"

cbaa58a

Keep the existing v3 handler existence check unchanged. This reverts commit b30d485. Signed-off-by: Marcin-Here <ext-marcin.grabowski@here.com>

CASL-1962: use executeRead/executeWrite and filter Spaces without the…

5fb7dbf

… deprecated property query Signed-off-by: Marcin-Here <ext-marcin.grabowski@here.com>

CASL-1962: use Platform.javaProxy instead of the deprecated JvmBoxing…

4029d9b

…Util.box Signed-off-by: Marcin-Here <ext-marcin.grabowski@here.com>

CASL-1962: lib-psql test for verifyNewHeadState covering each immutab…

28e36d2

…le field Signed-off-by: Marcin-Here <ext-marcin.grabowski@here.com>

This comment was marked as off-topic.

Sign in to view

Marcin-Here force-pushed the v3_Naksha_48-custom_indices branch from fe3d5d5 to 8c977f2 Compare October 8, 2026 07:35

This comment was marked as off-topic.

Sign in to view

v3_CASL_1962: autoCreateCollection off fix

a94f7b3

Signed-off-by: Marcin-Here <ext-marcin.grabowski@here.com>

This comment was marked as off-topic.

Sign in to view

v3_CASL_1962: uncesseary kotlin files changed to java

fee33a1

Signed-off-by: Marcin-Here <ext-marcin.grabowski@here.com>

This comment was marked as off-topic.

Sign in to view

v3_CASL_1962: check collections for sublcasses of DSH

6f0da3d

Signed-off-by: Marcin-Here <ext-marcin.grabowski@here.com>

This comment was marked as off-topic.

Sign in to view

hirenkp2000 requested changes Oct 12, 2026

View reviewed changes

gunplar reviewed Oct 12, 2026

View reviewed changes

xeus2001 previously approved these changes Oct 13, 2026

View reviewed changes

Marcin-Here added 3 commits October 14, 2026 09:02

v3_CASL_1962: review changes

201128a

Signed-off-by: Marcin-Here <ext-marcin.grabowski@here.com>

v3_CASL_1962: PropertyMemberQueryTranslator changes

4af8fec

Signed-off-by: Marcin-Here <ext-marcin.grabowski@here.com>

v3_CASL_1962: PropertyMemberQueryTranslator TagList and TagMap support

bf24efa

Signed-off-by: Marcin-Here <ext-marcin.grabowski@here.com>

Marcin-Here dismissed xeus2001’s stale review via bf24efa October 14, 2026 07:07

v3_CASL_1962: removed bloated logic.

9888b46

Signed-off-by: Marcin-Here <ext-marcin.grabowski@here.com>

v3_CASL_1962: removed unecessary request copy

f2b1827

Signed-off-by: Marcin-Here <ext-marcin.grabowski@here.com>

hirenkp2000 requested changes Oct 19, 2026

View reviewed changes

Marcin-Here added 5 commits October 20, 2026 20:17

v3_CASL_1962: customCollection mappings validation only on updates.

c04327d

Signed-off-by: Marcin-Here <ext-marcin.grabowski@here.com>

v3_CASL_1962: simplified 'adapt' to single collection argument

c7c8b9d

Signed-off-by: Marcin-Here <ext-marcin.grabowski@here.com>

v3_CASL_1962: added comment

0b8589e

Signed-off-by: Marcin-Here <ext-marcin.grabowski@here.com>

v3_CASL_1962: modularising adapt into 2 methods.

10553ea

Signed-off-by: Marcin-Here <ext-marcin.grabowski@here.com>

v3_CASL_1962: added comment for missing translation for Member Type

7b634e7

Signed-off-by: Marcin-Here <ext-marcin.grabowski@here.com>

hirenkp2000 requested changes Oct 21, 2026

View reviewed changes

v3_CASL_1962: Custom Members and Indices are created on first access …

c125ca9

…from NakshaCollection.kt Signed-off-by: Marcin-Here <ext-marcin.grabowski@here.com>

hirenkp2000 requested changes Oct 26, 2026

View reviewed changes

v3_CASL_1962: moved genereteCustomMembers and Indices logic into useM…

b23694c

…embers. Signed-off-by: Marcin-Here <ext-marcin.grabowski@here.com>

v3_CASL_1962: renamed CustomIndexMappings to CustomIndexMappingUtil.kt

0541059

Signed-off-by: Marcin-Here <ext-marcin.grabowski@here.com>

hirenkp2000 approved these changes Oct 27, 2026

View reviewed changes

Marcin-Here merged commit 3d7ef94 into v3 Oct 27, 2026
3 checks passed

Marcin-Here deleted the v3_Naksha_48-custom_indices branch October 27, 2026 08:58

Conversation

Marcin-Here commented Oct 8, 2026

Uh oh!

This comment was marked as off-topic.

This comment was marked as off-topic.

This comment was marked as off-topic.

This comment was marked as off-topic.

This comment was marked as off-topic.

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

xeus2001 left a comment

Choose a reason for hiding this comment

Uh oh!

github-actions Bot commented Oct 14, 2026

Code Coverage

Uh oh!

github-actions Bot commented Oct 14, 2026

Code Coverage

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment