[TYPO3-team-core-v5] RFC: fluent interface to query persistence

[Karsten Dambekalns]

Hi Bastian.

Bastian Waidelich wrote:
> Though I don't really understand why you have to pass the query-object 
> to the "subquery" in:
  ...
> It could be just
> 
> $posts = $query
>     ->matching('title', '~', '%FLOW3%')
>     ->orMatching(
>       ->matching('content', '~', 'cool')
       ^^^^^ what object?
>       ->andMatching('title', '~', '%TYPO3')
>     )
>     ->execute();
> 
> or am I missing something?

Yes: What object is the second "matching" called on?

>  > Easy (enough)?
> 
> Yes, I think so. Maybe the criteria operator could be a Constant. So 
> instead of:
> 
> ->matching('title', '~', '%FLOW3%')
> 
> something like:
> 
> ->matching('title', F3_PHPCR_Query::OPERATOR_LIKE, '%FLOW3%')

Internally the operators are matched against constants. But, be honest: 
What would you rather like to type?
  ~
or
  F3_FLOW3_Persistence_Query_QueryInterface::LikeOperator
Because that's what it is... You can use the constant, of course.

> or even a new method:
> 
> ->matchingLike('title', '%FLOW3%')
> 
> This way we'd had better IDE-support (code-hinting) and the chance of 
> typos could be reduced.

Good idea. I'll try to see how something like that feels like.

>  > Misses something?
> 
> You don't specify any action (like "select" or "retrieve") in your 
> examples. So how would a writing query look like?

There are no write queries. It's as simple as that. Here we go:
1. The Blog package has a BlogRepository for Blog objects.
2. When you add a Blog object to that Repository it will be persisted 
transparently, along with the data it holds (Aggregate).
3. Result: You only need to query for things. No write.

> Did you have a look at the Query language of Doctrine: 

Been there, done that. That language is close to SQL, which has a lot of 
shortcomings, the most severe one being that people will think it is SQL 
and then expect it to do much more than it should. And I would like to 
avoid writing a parser (or using one from some other project).

Anyway, I'll look at it again and of course there is also the JSR-283 
Query Object Model, but that sports a very cumbersome syntax.

Regards,
Karsten