nextcloud / nextcloud/tables

replace deprecated getQueryPart() in ContextMapper

Open
#1,740 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

1. to develop technical debt
Dominant language
JavaScript
Stars
214
Forks
52
Avg merge
1d 10h
Merged PRs (30d)
82

Description

  • Doctrine 4 removed getQueryPart() (PR)
  • … and marked it as deprecated in 3.8 (PR)
  • So it is also marked as deprecated in NCs abstraction (PR) as of NC 30

Money quote:

This function is going to be removed with the next Doctrine/DBAL update and we can not fix this in our wrapper. Please track the details you need, outside the object.

We use it in one place to figure out whether a WHERE condition is already set to know whether we either have to use where() or andWhere() in that method. Cf. https://github.com/nextcloud/tables/blob/1849033dbc6061f053dca4012dc2c4fd01ec61be/lib/Db/ContextMapper.php#L316-L320

Server wants to bump to Doctrine 4 in the upcoming version.

  • Figure out whether we can solve it with available methods
  • If so, implement the changes in a backwards compatible manner
  • If not so, bring up necessary changes to the IQueryBuilder abstraction in server and follow up

Side effect: currently there is potential deprecation log spam against >= NC 30.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with lib/Db/ContextMapper.php around lines 316-320 and review the Doctrine DBAL deprecation and removal references in the issue. Check whether available query-builder methods support the existing behavior while preserving compatibility. If not, follow the required changes to the server-side IQueryBuilder abstraction; done means the deprecated call is no longer needed and the compatibility path is addressed.

Written by the indexing model from the issue text.

Assessment

Tech stack
php
Domain
backend, database
Issue type
Refactor
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.