AliceBundle

When upgrading from version 0.2 to 1.x, apply the following changes:

Data Loaders

• Implementation: Data loaders must now either extend Hautelook\AliceBundle\Doctrine\DataFixtures\AbstractLoader or implement Hautelook\AliceBundle\Doctrine\DataFixtures\LoaderInterface.
• Simplified Logic: If you were overriding the ::load() function, you likely no longer need to. Custom Faker providers and Alice processors can now be registered directly.
• Bundle Referencing: Instead of using long paths to refer to fixtures in other bundles, use the @Bundlename annotation.
• Environment Management: Instead of using multiple data loaders to manage different fixture sets per environment, use environment-specific fixtures.

Doctrine Commands

• Replace the standard doctrine:fixtures:load command with the bundle-specific command: hautelook_alice:doctrine:fixtures:load (or the alias h:d:f:l).

DoctrineFixturesBundle Compatibility

• HautelookAliceBundle is compatible with DoctrineFixturesBundle, but it is recommended to use only one of them to avoid redundancy.

To use custom data generation logic in your fixtures, you can create a custom Faker Provider class and register it as a service.

There are two ways to register these services:

1. Manual Tagging: Explicitly add the nelmio_alice.faker.provider tag to your service definition in config/services.yaml.
2. Autoconfiguration: If autoconfigure is enabled in your Symfony configuration, you can omit the tag if your provider class extends Faker\Provider\Base.

Once registered, you can call your provider's methods within your fixture files using the <method_name(arguments)> syntax.

<?php

namespace AppBundle\DataFixtures\Faker\Provider;

class FooProvider
{
    public static function foo($str)
    {
        return 'foo'.$str;
    }
}

// In config/services.yaml
services:
    AppBundle\DataFixtures\Faker\Provider\FooProvider:
        tags: [ { name: nelmio_alice.faker.provider } ]

// In your fixtures (e.g., fixtures/orm/dummy.yml)
AppBundle\Entity\Dummy:
    brand{1..10}:
        name: <foo('a string')>

When upgrading from version 1.x to 2.x, several breaking changes and architectural shifts occur:

• Data Loaders: Remove custom DataLoaders. To reference files in different folders, use a "dummy" file containing an include statement instead.
• Persistence Layer: The persistence layer has moved to FidryAliceDataFixtures. Database-related configuration should now follow that library's documentation.
• Configuration Migration: Because Alice now ships with a Symfony bundle, some configuration elements have moved from HautelookAliceBundle to NelmioAliceBundle.
• Fixture Locations: The default and recommended location for fixtures has changed from src/AppBundle/DataFixtures{/ORM} to Resources/fixtures{/orm} (relative to your app or bundle).
• Service Tags:
  • Faker providers: Use nelmio_alice.faker.provider (previously hautelook_alice.faker.provider).
  • Processors: Use fidry_alice_data_fixtures.processor (previously hautelook_alice.alice.processor).

By default, fixtures are not validated. To trigger validation (e.g., using Symfony's Validator) during the fixture loading process, implement the ProcessorInterface and use the preProcess method.

Implementation:

1. Implement ProcessorInterface.
2. Inject ValidatorInterface into your constructor.
3. In preProcess, validate the $object and throw a DomainException if violations are found.

Example:

final class ArticleProcessor implements ProcessorInterface
{
    public function __construct(private readonly ValidatorInterface $validator) {}

    public function preProcess(string $id, object $object): void
    {
        $violations = $this->validator->validate($object);
        if ($violations->count() > 0) {
            throw new DomainException("Error when validating fixture $id: $violations");
        }
    }

    public function postProcess(string $id, object $object): void {}
}

To control the order in which objects are actually persisted to the database, you can decorate the fidry_alice_data_fixtures.loader.simple service by implementing a custom LoaderInterface.

Implementation Steps:

1. Create a class implementing LoaderInterface that decorates the existing loader.
2. In the load method, call the decorated loader to get the $objects array.
3. Re-order the $objects array as needed.
4. Register the class in services.yaml using the decorates attribute.

Example:

final class CustomOrderLoader implements LoaderInterface
{
    use IsAServiceTrait;
    private $decoratedLoader;

    public function __construct(LoaderInterface $decoratedLoader)
    {
        $this->decoratedLoader = $decoratedLoader;
    }

    public function load(array $fixturesFiles, array $parameters = [], array $objects = [], PurgeMode $purgeMode = null): array
    {
        $objects = $this->decoratedLoader->load($fixturesFiles, $parameters, $objects, $purgeMode);
        // TODO: re-order $objects
        return $objects;
    }
}

// services.yaml
services:
    Acme\Alice\Loader\CustomOrderLoader:
        decorates: 'fidry_alice_data_fixtures.loader.simple'
        arguments:
            - '@Acme\Alice\Loader\CustomOrderLoader.inner'