Bolt: [BUG] $app['query']->getContent when fetching content that has a relationship with self

Created on 19 May 2017  Â·  5Comments  Â·  Source: bolt/bolt

When defining a contenttype with a relationship to itself (e.g. pages has a relationship to pages), you'll get a QueryException (\Doctrine\DBAL\Query\QueryException\):

QueryException in QueryException.php line 50:

The given alias 'pages' is not unique in FROM and JOIN clause table.
The currently registered aliases are: pages.

Details

  • Relevant Bolt Version: [ 3.2.13 ]
  • Install type: [ Zip/tarball install | Composer install ]
  • PHP version: [ 5.6 ]
  • Used web server: [ Apache ] version [ 2.2.22 ]

Reproduction

  • Have a regular Bolt installation.
  • Open contenttypes.yml and add a pages relationship to pages:
pages:
    (...)
    relations:
        pages:
          multiple: false
          order: title
          label: Select a page
$app['query']->getContent('pages', []);

or

$app['query']->getContent('pages', [ 'id' => 1 ]);

Potential Solution

I'm not sure... but it might a solution to prefix relationships, and then prefix the parameter fields that are relationships (if it can be done consistently).

Then there's the potential issue with field/column name == relationship/taxonomy name (not necessarily related).

blocking release bug

Most helpful comment

@anketwokings I know Ross is working on a fix, and it is proving troublesome. However, the work around in the comment above yours of setting an alias: key/value does work as I ran into this too and had to use that as a workaround.

Past that, I'll let Ross chime in on his E.T.A. :smile:

All 5 comments

@rossriley Is this one still on your radar?

OK, there is both a workaround and a fix to come shortly.

The workaround is that the relations field supports an alias setting so you can do:

relations:
        pages:
            multiple: false
            order: title
            label: Select a page
            alias: relatedpages

This was designed in for supporting of multiple relations to the same contenttype.

The mistake is that whilst we should have a unique constraint on the field names, that is a field name should be unique on a contenttype, we probably need to 1) validate this and throw proper errors and 2) make sure that built in aliases don't create reserved words.

So, I'll tweak the select query to add an underscore to the contenttype... SELECT * from bolt_pages _pages WHERE ... rather than SELECT * from bolt_pages pages WHERE ... and this will allow pages to be used as a field name.

PR coming soon, just need to do a bit of testing.

Is there a planning when this might be solved? I could use this fix in a client project, and would like to communicate some kind of timespan when it might be solved. Thank you!

@anketwokings I know Ross is working on a fix, and it is proving troublesome. However, the work around in the comment above yours of setting an alias: key/value does work as I ran into this too and had to use that as a workaround.

Past that, I'll let Ross chime in on his E.T.A. :smile:

… and then 10 minutes later, PR 6779 hits the PR queue. Our team ninja is at it again :rofl:

Was this page helpful?
0 / 5 - 0 ratings

Related issues

xiaohutai picture xiaohutai  Â·  3Comments

GwendolenLynch picture GwendolenLynch  Â·  5Comments

zomars picture zomars  Â·  5Comments

ankedsgn picture ankedsgn  Â·  4Comments

dolcy picture dolcy  Â·  5Comments