slendium/ocd
Watch
1
0
Fork
You've already forked ocd
 0
Code Issues 25 Pull requests Projects Releases Packages Wiki Activity Actions

Querying #2

New issue
Closed
opened 2026-07-14 15:39:45 +02:00 by c.fahner · 2 comments
c.fahner commented 2026-07-14 15:39:45 +02:00
Owner
Copy link

Most methods of the Collection interface depend on being able to specify a filter.

The following query operations seem to be supported by both MongoDB and SQL:

  • Checking if a field is "empty" (or does not exist)
  • Checking if a field exactly matches a certain value
  • Checking if a field is of a certain type
  • Numeric comparisons (<, <=, >, >=)
  • Matching none, at least one or all elements in a list ("all" applying only to nested lists)
  • Matching a regular expression (PCRE seems to be broadly supported)
  • Combining any of the above using AND, OR or NOT operators

This would be a perfect use case for tagged unions, but sadly this RFC is still in draft.

Every operation will be implemented as an AST node. A Predicate base class will contain static "query builder" methods while a provided "visitor" interface can be used by implementors to cover all cases.

Most methods of the `Collection` interface depend on being able to specify a filter. The following query operations seem to be supported by both MongoDB and SQL: * Checking if a field is "empty" (or does not exist) * Checking if a field exactly matches a certain value * Checking if a field is of a certain type * Numeric comparisons (`<, <=, >, >=`) * Matching none, at least one or all elements in a list ("all" applying only to nested lists) * Matching a regular expression (PCRE seems to be broadly supported) * Combining any of the above using AND, OR or NOT operators This would be a perfect use case for [tagged unions](https://wiki.php.net/rfc/tagged_unions), but sadly this RFC is still in draft. Every operation will be implemented as an AST node. A `Predicate` base class will contain static "query builder" methods while a provided "visitor" interface can be used by implementors to cover all cases.
c.fahner added this to the v0.1 milestone 2026-07-14 15:39:45 +02:00
c.fahner added spent time 2026-08-04 19:49:32 +02:00
45 minutes
c.fahner added spent time 2026-08-05 18:51:13 +02:00
40 minutes
c.fahner added spent time 2026-08-06 19:09:21 +02:00
1 hour 20 minutes
c.fahner added spent time 2026-08-07 19:38:03 +02:00
2 hours 10 minutes
c.fahner stopped working 2026-08-09 10:47:01 +02:00
2 hours 16 minutes
c.fahner added spent time 2026-08-10 20:00:42 +02:00
35 minutes
c.fahner added spent time 2026-08-12 19:00:40 +02:00
1 hour 20 minutes
c.fahner added spent time 2026-08-13 19:38:29 +02:00
50 minutes
c.fahner commented 2026-08-14 19:36:43 +02:00
Author
Owner
Copy link

Decided to remove the Not operand to limit the amount of expression objects generated. Introduced NotEqual, NotExists and NotOfType to cover the gap.

Allowing users to build one predicate and then negate it does not really make sense when they could just construct the negated expression immediately. This saves object allocations at the declaration site and reduces the amount of objects to process on the database-implementation side.

Decided to remove the `Not` operand to limit the amount of expression objects generated. Introduced `NotEqual`, `NotExists` and `NotOfType` to cover the gap. Allowing users to build one predicate and then negate it does not really make sense when they could just construct the negated expression immediately. This saves object allocations at the declaration site and reduces the amount of objects to process on the database-implementation side.
c.fahner added spent time 2026-08-14 20:02:50 +02:00
1 hour 15 minutes
c.fahner stopped working 2026-08-15 09:50:53 +02:00
59 minutes 37 seconds
c.fahner commented 2026-08-15 10:20:59 +02:00
Author
Owner
Copy link

Decided not to reject NAN or INF values during query building since it would add checks + branches for a rare edge case. Presumably SQL-based databases or their drivers will reject these cases already.

Only MongoDB seems to allow these kinds of values so for compatibility they should be rejected at some point. The data model should just be forced to reserve a separate column that indicates these values if needed (eg. enum with finite, NaN and Infinite cases).

Decided not to reject `NAN` or `INF` values during query building since it would add checks + branches for a rare edge case. Presumably SQL-based databases or their drivers will reject these cases already. Only MongoDB seems to allow these kinds of values so for compatibility they should be rejected at some point. The data model should just be forced to reserve a separate column that indicates these values if needed (eg. enum with finite, NaN and Infinite cases).
c.fahner added spent time 2026-08-18 18:13:16 +02:00
20 minutes
c.fahner referenced this issue from a commit 2026-08-18 18:20:02 +02:00
Querying (#17)
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
v0.1.0
Labels
Clear labels   
Compat/Breaking
Breaking change that won't be backward compatible

  
Kind/Bug
Something is not working

  
Kind/Documentation
Documentation changes

  
Kind/Enhancement
Improve existing functionality

  
Kind/Feature
New functionality

  
Kind/Research
Research whether or not a change is worth it.

  
Kind/Security
This is security issue

  
Kind/Testing
Issue or pull request related to testing

  
Priority
Critical
 The priority is critical

  
Priority
High
 The priority is high

  
Priority
Low
 The priority is low

  
Priority
Medium
 The priority is medium

  
Reviewed
Confirmed
 Issue has been confirmed

  
Reviewed
Duplicate
 This issue or pull request already exists

  
Reviewed
Invalid
 Invalid issue

  
Reviewed
Won't Fix
 This issue won't be fixed

  
Status
Abandoned
 Somebody has started to work on this but abandoned work

  
Status
Blocked
 Something is blocking this issue or pull request

  
Status
Need More Info
 Feedback is required to reproduce issue or to continue work

No labels
Compat/Breaking
Kind/Bug
Kind/Documentation
Kind/Enhancement
Kind/Feature
Kind/Research
Kind/Security
Kind/Testing
Priority
Critical
Priority
High
Priority
Low
Priority
Medium
Reviewed
Confirmed
Reviewed
Duplicate
Reviewed
Invalid
Reviewed
Won't Fix
Status
Abandoned
Status
Blocked
Status
Need More Info
Milestone
Clear milestone
No items
No milestone
v0.1
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Total time spent: 12 hours 31 minutes
c.fahner
12 hours 31 minutes
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Blocks
#3 Data manipulation
slendium/ocd
#15 Database and collection access objects
slendium/ocd
Reference
slendium/ocd#2
No description provided.