DEV Community

Cover image for AI and Development: Avoiding Common Traps
Nicolas Dabene
Nicolas Dabene

Posted on • Originally published at nicolas-dabene.fr

AI and Development: Avoiding Common Traps

#prestashop #ecommerce #ai

Seamlessly Handling PrestaShop's Dynamic DB Prefixes with Doctrine

Developing modules for PrestaShop using Doctrine can often lead to a perplexing issue: the dreaded "Base table or view not found" error, even when you're certain your table exists. This common pitfall arises because PrestaShop dynamically prepends a prefix to its database tables, a detail Doctrine's default behavior overlooks.

Having navigated PrestaShop development for over 15 years, I've seen this specific problem derail countless projects. Today, I'm excited to share an elegant and robust method to resolve this using a custom Doctrine event subscriber.

The Frustrating Symptom That Consumes Hours

Picture this scenario: You've meticulously crafted your Doctrine entity with precise annotations, and you fire off your inaugural query. Suddenly, you're greeted with a jarring error:

SQLSTATE[42S02]: Base table or view not found: 1146 Table 'shop.trade_in_request' doesn't exist
Enter fullscreen mode Exit fullscreen mode

Yet, a quick check of your database reveals the table is indeed present, but it's named ps_trade_in_request or shop_trade_in_request, depending on the unique prefix established during your PrestaShop installation. This discrepancy is the root of the headache.

Understanding Doctrine's Table Search Mismatch

The core of this problem lies in the architectural differences between PrestaShop and Doctrine's default operational assumptions:

PrestaShop's Adaptable Prefixes

PrestaShop utilizes a variable table prefix, stored in the _DB_PREFIX_ constant. This prefix can differ significantly across various installations:

  • ps_ (the typical default)
  • shop_ (common in custom setups)
  • abc123_ (often used for enhanced security)
  • And a multitude of other unique configurations...

Doctrine's Strict Annotation Interpretation

When you define your entity with a simple annotation like this:

/**
 * @ORM\Table(name="trade_in_request")
 * @ORM\Entity()
 */
class TradeInRequest
{
    // Your properties...
}
Enter fullscreen mode Exit fullscreen mode

Doctrine strictly adheres to the provided name value. It will search exclusively for the trade_in_request table, never inferring or appending the PrestaShop-specific prefix.

The Pitfall: Hardcoding the Prefix

The immediate, yet fundamentally flawed, temptation is to hardcode the prefix directly into your entity definitions:

/**
 * @ORM\Table(name="ps_trade_in_request") // ❌ AVOID THIS!
 * @ORM\Entity()
 */
class TradeInRequest {}
Enter fullscreen mode Exit fullscreen mode

This approach introduces severe limitations and violates best practices:

  • It ties your module to a specific prefix, breaking on other installations.
  • Makes multi-environment deployments unnecessarily complicated.
  • Goes against PrestaShop's recommended development guidelines.

The Elegant Resolution: A Doctrine Event Subscriber

The most effective method is to intercede during Doctrine's metadata loading process and inject the correct PrestaShop database prefix dynamically.

Step 1: Crafting the Subscriber Class

Create a new file, src/Doctrine/TablePrefixSubscriber.php, within your module's structure:

<?php

namespace Vendor\YourModule\Doctrine;

use Doctrine\Common\EventSubscriber;
use Doctrine\ORM\Events;
use Doctrine\ORM\Event\LoadClassMetadataEventArgs;

class TablePrefixSubscriber implements EventSubscriber
{
    public function __construct(
        private readonly string $dbPrefix
    ) {}

    public function getSubscribedEvents(): array
    {
        return [Events::loadClassMetadata];
    }

    public function loadClassMetadata(LoadClassMetadataEventArgs $args): void
    {
        $classMetadata = $args->getClassMetadata();

        // Restrict this subscriber to your module's entities only
        $moduleNamespace = 'Vendor\\YourModule\\Entity\\';
        if (!str_starts_with($classMetadata->getName(), $moduleNamespace)) {
            return; // Exit if not one of our entities
        }

        $this->prefixTableName($classMetadata);
        $this->prefixJoinTables($classMetadata);
    }

    private function prefixTableName($classMetadata): void
    {
        $tableName = $classMetadata->getTableName();

        if (!str_starts_with($tableName, $this->dbPrefix)) {
            $classMetadata->setPrimaryTable([
                'name' => $this->dbPrefix . $tableName
            ]);
        }
    }

    private function prefixJoinTables($classMetadata): void
    {
        foreach ($classMetadata->getAssociationMappings() as &$mapping) {
            if (isset($mapping['joinTable']['name'])) {
                $joinTableName = $mapping['joinTable']['name'];

                if (!str_starts_with($joinTableName, $this->dbPrefix)) {
                    $mapping['joinTable']['name'] = $this->dbPrefix . $joinTableName;
                }
            }
        }
    }
}
Enter fullscreen mode Exit fullscreen mode

Step 2: Registering the Service

In your module's config/services.yml file, declare your new subscriber as a service:

services:
  Vendor\YourModule\Doctrine\TablePrefixSubscriber:
    arguments:
      - '%database_prefix%'
    tags:
      - { name: doctrine.event_subscriber }
Enter fullscreen mode Exit fullscreen mode

Step 3: Maintaining Clean Entity Definitions

With the subscriber in place, your Doctrine entities can remain blissfully unaware of PrestaShop's prefixing rules:

<?php

namespace Vendor\YourModule\Entity;

use Doctrine\ORM\Mapping as ORM;

/**
 * @ORM\Table(name="trade_in_request")
 * @ORM\Entity(repositoryClass="Vendor\YourModule\Repository\TradeInRequestRepository")
 */
class TradeInRequest
{
    /**
     * @ORM\Id
     * @ORM\GeneratedValue
     * @ORM\Column(type="integer")
     */
    private int $id;

    /**
     * @ORM\Column(type="string", length=255)
     */
    private string $customerEmail;

    /**
     * @ORM\Column(type="datetime")
     */
    private \DateTime $createdAt;

    // Getters and setters...
}
Enter fullscreen mode Exit fullscreen mode

Step 4: Aligning Your Installation SQL

Crucially, ensure your sql/install.sql script also respects the dynamic prefix by using the {$prefix} variable:

CREATE TABLE IF NOT EXISTS `{$prefix}trade_in_request` (
    `id` int(11) NOT NULL AUTO_INCREMENT,
    `customer_email` varchar(255) NOT NULL,
    `created_at` datetime NOT NULL,
    PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;
Enter fullscreen mode Exit fullscreen mode

Implementing the Solution

After introducing these changes, a couple of steps are required to ensure they take effect:

Clear Symfony Cache 

bin/console cache:clear --no-warmup
Enter fullscreen mode Exit fullscreen mode

Reset Your Module 

bin/console prestashop:module reset yourmodule --no-interaction
Enter fullscreen mode Exit fullscreen mode

Alternatively, you can achieve this through the PrestaShop back office by uninstalling and then reinstalling your module.

Effortless Management of Complex Relationships

A fantastic benefit of this subscriber is its automatic handling of join tables. For instance, in a ManyToMany relationship:

/**
 * @ORM\ManyToMany(targetEntity="Category")
 * @ORM\JoinTable(name="trade_in_request_category",
 *     joinColumns={@ORM\JoinColumn(name="request_id", referencedColumnName="id")},
 *     inverseJoinColumns={@ORM\JoinColumn(name="category_id", referencedColumnName="id")}
 * )
 */
private Collection $categories;
Enter fullscreen mode Exit fullscreen mode

The trade_in_request_category table will automatically be transformed into {prefix}trade_in_request_category by our diligent subscriber.

Verifying Your Implementation

To confirm everything is working as expected, a simple test case can be invaluable:

<?php

namespace Vendor\YourModule\Tests;

use Vendor\YourModule\Entity\CustomerReview;
use Symfony\Bundle\FrameworkBundle\Test\KernelTestCase;

class TablePrefixTest extends KernelTestCase
{
    public function testTablePrefixIsApplied(): void
    {
        self::bootKernel();

        $entityManager = self::getContainer()->get('doctrine.orm.entity_manager');
        $metadata = $entityManager->getClassMetadata(CustomerReview::class);

        // Confirm the prefix is correctly applied
        $expectedTableName = _DB_PREFIX_ . 'customer_review';
        $this->assertEquals($expectedTableName, $metadata->getTableName());
    }
}
Enter fullscreen mode Exit fullscreen mode

Key Benefits of This Strategy

Adopting this event subscriber method yields significant advantages in your module development:

Universal Compatibility

  • Works flawlessly across all PrestaShop database prefixes.
  • Eliminates environment-specific code adjustments.
  • Streamlines deployment across diverse PrestaShop instances.

Simplified Maintenance

  • Centralizes the entire table prefixing logic in one place.
  • Prevents redundant code, enhancing overall code quality.
  • Guarantees greater scalability for future module enhancements.

Adherence to Standards

  • Fully aligns with PrestaShop's recommended development best practices.
  • Promotes clean, highly readable business logic within your entities.
  • Ensures a clear separation of concerns, making your code more modular.

Important Considerations

While this approach is powerful, keep these vital points in mind:

Limiting the Subscriber's Scope

Always ensure your subscriber exclusively targets your module's entities:

$moduleNamespace = 'Vendor\\YourModule\\Entity\\';
if (!str_starts_with($classMetadata->getName(), $moduleNamespace)) {
    return; // Crucial: Do not interfere with other entities or PrestaShop core
}
Enter fullscreen mode Exit fullscreen mode

This safeguard prevents potential conflicts with other modules or PrestaShop's core tables.

Maintaining SQL/Doctrine Consistency

Verify that your SQL installation scripts use the same base table names as your Doctrine entities:

  • Entity: @ORM\Table(name="my_table")
  • SQL: CREATE TABLE {$prefix}my_table

Thorough Real-World Testing

Always test your module with different database prefixes to thoroughly validate your implementation:

// Within your test environment setup
define('_DB_PREFIX_', 'test_');
Enter fullscreen mode Exit fullscreen mode

Conclusion

Managing dynamic table prefixes with Doctrine in PrestaShop might seem daunting at first glance, but with this event subscriber technique, it becomes a straightforward and robust process. This approach not only provides a highly maintainable solution but also gracefully respects the platform's architectural nuances.

The next time you embark on PrestaShop module development with Doctrine, remember to integrate this subscriber from the outset. Your future self – and your fellow developers – will certainly appreciate the foresight!

Found this guide helpful? For more in-depth PHP and PrestaShop development insights, tutorials, and practical tips, make sure to check out my content!

Top comments (2)

Collapse
 
notadevbuthere profile image
Urvisha Maniar •

AI is moving so fast that it’s easy to fall into these traps without realizing it.
Loved how clearly you explained the common mistakes and how to avoid them. Tools like CodeDoc, GitBook, and Notion really help simplify things for people like me who aren’t super technical. 😊

Collapse
 
ndabene profile image
Nicolas Dabene •

Thank you for the feedback :)