Download the PHP package andanteproject/shared-query-builder without Composer

Shared Query Builder

Doctrine 2/3 Query Builder decorator - AndanteProject

A Doctrine 2 Query Builder decorator that makes it easier to build your query in shared contexts.

Table of contents

• Why do I need this?
• Features
• Requirements
• Install
• Set up
• Which additional methods do I have?
  • Entity methods
  • Lazy joins
  • Proposals
  • Creating a proposal
  • Collect API (no side effects until use)
  • Merging by use
  • Consumed state and reuse
  • Introspection and clear
  • Example: filter as a proposal
• Examples
  • A real world case
  • That's why SharedQueryBuilder is going to save your ass in these situations
  • Evolution: filters that receive and return a Proposal
  • Immutable Parameters
  • Set parameter and use it in expression at the same moment
  • Unique parameters
  • Conclusion

Why do I need this?

When your query business logic is big and complex you are probably going to split its building process to different places/classes.

Without SharedQueryBuilder there is no way to do that unless guessing Entity aliases and messing with join statements.

This query builder decorator addresses some problems you can find in a real world situation you usually solve with workarounds and business conventions.

Features

• Ask query builder which alias is used for an entity when you are outside its creation context;
• Lazy joins to declare join statements to be performed only if related criteria are defined;
• Immutable and unique query parameters;
• Proposals: collect conditions, joins, parameters (and select/groupBy/orderBy/having) in a temporary object and merge them into the main query by using the proposal in andWhere / orWhere—ideal for strategies or filters that need to contribute a whole “block” of DQL;
• Works like magic ✨.

Requirements

Doctrine 3 and PHP 8.0 or higher.

Install

Via Composer:

Set up

After creating your query builder, wrap it inside our SharedQueryBuilder.

From now on, you can use $sqb exactly as you usually do with query builder (every single method of QueryBuilder is available on SharedQueryBuilder), but with some useful extra methods 🤫.

When you're done building your query, just unwrap your SharedQueryBuilder.

Please note:

• The only condition applied to build a SharedQueryBuilder is that no join statements may be declared yet.
• SharedQueryBuilder is a decorator of QueryBuilder, which means it is not an instance of QueryBuilder even if it has all its methods (sadly, Doctrine has no QueryBuilder Interface 🥺).
• SharedQueryBuilder does not allow you to join an Entity multiple times with different aliases.

Which additional methods do I have?

Entity methods

You can ask the SharedQueryBuilder if it has and entity in the from statement or some join statements.

You can ask which is the alias of an Entity inside the query you're building (no matter if it is used in a from statement or a join statement).

You can use withAlias method to smoothly add a condition for that entity property:

Given an alias, you can retrieve its entity class:

QueryBuilder::getAllAliases is extended to have an optional bool argument $includeLazy (default:false) to include lazy joins aliases.

Lazy joins

All query builder join methods can be used as usual, but you can also use them with "lazy" prefix.

By doing this, you are defining a join statement without actually adding it to your DQL query. It is going to be added to your DQL query only when you add another condition/dql part which refers to it. Automagically ✨.

Based on how confused you are right now, you can check why you should need this or some examples to achieve your "OMG" revelation moment.

Proposals

When you split query building across multiple strategies or filter classes, you often want each one to contribute a block of logic: several conditions, joins, parameters, and maybe select/groupBy/orderBy/having. Proposals let you collect that block in a temporary object and “merge” it into the main SharedQueryBuilder in one go—by using the proposal inside andWhere, orWhere, where, andHaving, or orHaving. There is no separate merge() call: merging happens when the proposal is used in one of those methods.

Creating a proposal

Create an empty proposal from the SharedQueryBuilder; you can give it a name (useful for debugging) or leave it empty to get a unique auto-generated name.

Collect API (no side effects until use)

A proposal exposes the same method names as the SQB for building a local set of conditions, joins, parameters, and other parts. Nothing is written to the main query until the proposal is used in an expression. Build conditions with the proposal’s expr() (e.g. eq, neq, andX, orX) so they stay object-oriented. Never hardcode entity aliases—use the SQB’s withAlias(Entity::class, 'property') (or the proposal’s, which delegates to the SQB) so the library resolves the correct alias.

• Parameters: use only withUniqueImmutableParameter on the proposal; on expansion, parameter names are made unique on the main SQB and the condition DQL is updated accordingly.
• Nested proposals: you can add another proposal as a condition: $proposal->andWhere($nestedProposal). When the parent is expanded, nested proposals are expanded recursively.

Merging by use

To merge a proposal into the main query, pass it to andWhere, orWhere, where, andHaving, or orHaving. The SQB will expand the proposal (apply its joins, parameters, select/groupBy/orderBy/having, build the condition, and replace the proposal with the resulting DQL).

You can combine multiple proposals in an OR (or AND) by passing the proposals directly to expr()->orX() (or expr()->andX()). The SQB expands them when building the where clause; you do not need to call expandInto().

Consumed state and reuse

After a proposal is expanded for the first time, it is marked consumed. Using the same proposal again in another andWhere/orWhere is a no-op: it expands to a neutral 1=1 so the query result is unchanged. Cloning a proposal gives a non-consumed copy with the same collected state.

Introspection and clear

• Introspection: hasConditions(), hasJoins(), hasParameters(), isEmpty(), isConsumed().
• Clear: clearWhere(), clearJoins(), clearParameters(), clearSelect(), clearGroupBy(), clearOrderBy(), clearHaving(), clearAll().

Example: filter receives a proposal, fills it, returns it; merge at upper level

The caller (e.g. controller) creates an empty proposal and passes it to the filter. The filter receives the request and that proposal; it fills the proposal using the proposal’s methods (e.g. withAlias(Entity::class, 'property'), which delegates to the SQB) so aliases are never hardcoded, then returns the same proposal. The caller is responsible for merging the proposal into the query. That way the filter only builds its block of logic; where and how it is combined (e.g. andWhere vs orWhere) stays at the upper level.

This keeps the filter responsible only for building its conditions and parameters (using withAlias so the library resolves entity aliases); the caller decides how to merge and avoids alias or parameter name clashes between filters.

Examples

Let's suppose we need to list User entities but we also have an optional filter to search a user by their address Building name.

There is no need to perform any join until we decide to use that filter. We can use Lazy Join to achieve this.

You are probably thinking: why don't we achieve the same result with the following, more common, way? (keep in mind that avoiding unnecessary joins is still a requirement)

The code above is perfectly fine if you build this whole query in the same context:

• 👍 You are aware of the whole query building process;
• 👍 You are aware of which entities are involved;
• 👍 You are aware of which alias are defined for each entity.
• 👍 You are aware of which query parameters are defined and their purpose.

But you have problems:

• 👎 You are mixing query structure definition with optional filtering criteria.
• 👎 Code is quickly going to be an unreadable mess.

A real world case

If your query structure grows with lots of joins and filtering criteria, you are probably going to split all that business logic in different classes.

For instance, in a backoffice Users list, you are probably going to define your main query to list entities in your controller and handle optional filters in some other classes.

Filter classes may look like this:

We are committing some multiple sins here! 💀 The context is changed.

• 👎 You are not aware of the whole query building process. Is the given QueryBuilder even a query on User entity?;
• 👎 You are not aware of which entities are involved. Which entities have already been joined?;
• 👎 You are not aware of which aliases are defined for each entity. No way we are calling u.address by convention 🤨;
• 👎 You are aware of what parameters have been defined ($qb->getParameters()), but you are not aware why they have been defined, for which purpose and you can also override them changing elsewhere behavior;
• 👎 Our job in this context is just to apply some filter. We can change the query by adding some join statements but we should avoid that. What if another filter also need to perform those joins? Devastating. 😵

That's why SharedQueryBuilder is going to save your ass in these situations

Let's see how we can solve all these problems with SharedQueryBuilder (you can now guess why it is named like this).

Using SharedQueryBuilder you can:

• 👍 Define lazy join to allow them to be performed only if they are needed;
• 👍 Define some parameters immutable to be sure value is not going to be changed elsewhere;
• 👍 You can check if an entity is involved in a query and then apply some business logic;
• 👍 You can ask the query builder which alias is used for a specific entity so you are not going to guess aliases or sharing them between classes using constants (I know you thought of that 🧐).

Filter classes will look like this:

• 👍 No extra join statements executed when there is no need for them;

Evolution: filters that receive and return a Proposal

You can go one step further: have each filter receive an empty Proposal (created by the caller), fill it using withAlias() and the proposal’s expr(), and return that proposal. The controller then merges each proposal (e.g. with andWhere) at the upper level. That keeps the same benefits (no hardcoded aliases, merge logic in one place) and makes each filter a pure “block builder” that never touches the SQB’s where clause directly.

Step 1: BuildingNameFilter receives and returns a Proposal

Step 2: Controller creates proposals, passes them to both filters, merges at upper level

• 👍 No extra join statements executed when there is no need for them;
• 👍 No way to change/override parameters value once defined;
• 👍 We can discover if the Query Builder is handling an Entity and then apply our business logic;
• 👍 We are not guessing entity aliases;
• 👍 Our filter class is only responsible for filtering;
• 👍 There can be multiple filter class handling different criteria on the same entity without having duplicated join statements;

Immutable Parameters

Shared query builder has Immutable Parameters. Once defined, they cannot be changed; otherwise an Exception will be raised.

Set parameter and use it in expression at the same moment

If you are sure you are not going to use a parameter in multiple places inside your query, you can write the following code 🙌

this way 👇👇👇

Unique parameters

Beside immutable parameters, you can also demand query builder the generation of a parameter name. Using the following methods, query builder will decorate names to avoid conflicts with already declared ones ( which cannot even happen with immutable parameters).

Conclusion

The world is a happier place 💁.

Give us a ⭐️ if your world is now a happier place too! 💃🏻

Built with love ❤️ by AndanteProject team.