data icon indicating copy to clipboard operation
data copied to clipboard

Abstract Query implementation from persistence specific ones

Open georgehristov opened this issue 4 years ago • 6 comments

The concept unifies the persistence query objects which must extend Persistence\AbstractQuery In the case of Persistence\Sql\Query the calls are forwarded to underlying DSQL object.

This abstracts the link to the actual query engine and unifies the use of Persistence\Query object in atk4/data irrelevant of persistence type.

The Model::load functionality has been moved to the Model object strictly leaving Persistence object to care only about raw data CRUD.

The Persistence CRUD methods have been moved to the generic Persistence class which relies on storage specific Query objects to perform the interaction with the data storage engine (Sql, Array (memory), Csv).

Array and Csv Query engines extend Persistence\IteratorQuery.

  • Array_ persistence is using \ArrayIterator
  • Csv persistence is using \SplFileObject which is also an iterator

If the concept is accepted it can be further worked on:

  • introduce Model\QueryTrait to introduce direct access to query methods (insert, select, delete, etc) and use in the model object
  • introduce optional Model\QueryAggregatesTrait to introduce direct access to aggregate methods (sum, avg, etc) and use in the model object
  • optimize code

BC break:

  • Model::action renamed to Model::toQuery
  • Persistence::action renamed to Persistence::query

georgehristov avatar Aug 02 '20 08:08 georgehristov

Now it is better 😄 diff

georgehristov avatar Aug 17 '20 13:08 georgehristov

Now it is better 😄 diff

Very good, I hope we can trash more! :D

About review: still waiting on @DarkSide666, I will review it then as we already did some iterations together.

mvorisek avatar Aug 17 '20 13:08 mvorisek

@romaninsh for sure but I would like to settle on the code first to avoid writing and rewriting. Update on docs is compulsory

georgehristov avatar Aug 18 '20 17:08 georgehristov

@romaninsh @DarkSide666 @mvorisek

One design issue to solve is whether to use a single pair of hooks for Query execution HOOK_BEFORE_EXECUTE and HOOK_AFTER_EXECUTE or maintain operation specific pairs. The query object is passed on to the hook closure as an argument so you can get the operation by $query->getMode(). The disadvantage is that such hooks are called on each operation.

https://github.com/atk4/data/blob/2d47db6537668fecb0b8fd87880d461b441ef6db/src/Persistence/AbstractQuery.php#L279-L296

georgehristov avatar Aug 19 '20 06:08 georgehristov

@georgehristov will looked quickly through, but will look again.

romaninsh avatar Aug 19 '20 07:08 romaninsh

Hi @georgehristov, the ship sailed already too much to be able to resolve the conflicts easily. Can you please rebase/redo this PR on top of the current develop branch or should this PR be closed?

mvorisek avatar Jul 30 '22 10:07 mvorisek

@georgehristov I am gonna to close this PR soon, if there is any value outside the rename of "action" to "query", I would happily integrate these improvements as a separate PR.

mvorisek avatar Aug 12 '23 14:08 mvorisek

Closing due inactivity. The persistence changes might be welcomed, but should be submit without the action->query refactoring, any big refactoring must be submit as a separate PR.

mvorisek avatar Sep 07 '23 14:09 mvorisek