Support for subqueries #93

New issue

Open

opened 2026-10-25 09:02:39 +01:00 by c.fahner · 2 comments

c.fahner commented

2026-10-25 09:02:39 +01:00

Owner

Currently it is not possible to query a collection based on the properties of a referenced object. For example, a User entity might have an Address $address property that references a object from the addresses collection. Finding all users that live in a certain city would require querying the path addresses.city, which should not be confused with a query to a JSON column containing an addresses.city path.

To solve this issue, two things must change:

It should be possible to distinguish nested paths from field paths
There should be some mechanism for predicates to resolve the collection names of referenced objects

One possibility is to introduce a ValuePath object to replace FieldPath's. This ValuePath then has two properties: non-empty-list<non-empty-string> $fieldPath and list<string> $innerPath. The $fieldPath traverses objects/entities and their references, where the last part selects the field on the final object. The (optional) $innerPath can then traverse into the object to retrieve values from nested values, such as JSON fields.

Currently it is not possible to query a collection based on the properties of a referenced object. For example, a `User` entity might have an `Address $address` property that references a object from the `addresses` collection. Finding all users that live in a certain city would require querying the path `addresses.city`, which should not be confused with a query to a JSON column containing an `addresses.city` path. To solve this issue, two things must change: * It should be possible to distinguish nested paths from field paths * There should be some mechanism for predicates to resolve the collection names of referenced objects One possibility is to introduce a `ValuePath` object to replace `FieldPath`'s. This `ValuePath` then has two properties: `non-empty-list<non-empty-string> $fieldPath` and `list<string> $innerPath`. The `$fieldPath` traverses objects/entities and their references, where the last part selects the field on the final object. The (optional) `$innerPath` can then traverse into the object to retrieve values from nested values, such as JSON fields.

c.fahner added this to the v0.3 milestone

2026-10-25 09:02:39 +01:00

c.fahner added the

Kind/Feature

label

2026-10-25 09:02:39 +01:00

c.fahner removed this from the v0.3 milestone

2026-10-25 09:03:04 +01:00

c.fahner commented

2026-10-25 09:34:08 +01:00

Author

Owner

Possibly related to #33.

c.fahner added this to the v0.3 milestone

2026-10-26 18:31:47 +01:00

c.fahner commented

2026-10-26 18:32:50 +01:00

Author

Owner

Re-added v0.3 milestone because the distinction between FieldPath and NestedPath should be made as soon as possible. FieldPath is already quite commonly used.

Re-added v0.3 milestone because the distinction between `FieldPath` and `NestedPath` should be made as soon as possible. `FieldPath` is already quite commonly used.

c.fahner referenced this issue

2026-10-28 15:36:09 +01:00

Add Field::fromClass() #100

c.fahner added a new dependency

2026-10-28 15:36:32 +01:00

#100 Add Field::fromClass()

c.fahner referenced this issue from slendium/ocd-conformance-tests

2026-10-29 06:45:07 +01:00

Add test for every type of predicate #10

c.fahner referenced this issue from slendium/ocd-conformance-tests

2026-10-29 16:34:11 +01:00

Add tests for multi-part field paths and inner paths #17