Managing monolithic repositories with composer’s path repository

Composer now have a new repository type in addition to, among others, the well known vcs for instance: the path repository. The goal if this repository is to be able to manage dependencies between applications and packages in a monolithic repository.

A monolithic repository?

The first question can be: why a monolithic repository? There are many blog posts and videos around about why such a code repository can be extremely useful for your project and your team, but we can quickly summarise that in some cases you’ll find at least these advantages:

  • Reduced bootstrap cost as new starters just need this repository
  • Easier to have cross-applications patches (via a single pull-request for instance)
  • You don’t need to download dependencies as they are here 😉

Obviously there are also some potential problems such as the ease of BC breaks between your libraries/applications and also shared responsibility, but that’s more related to the developers than the tooling.

Continue reading Managing monolithic repositories with composer’s path repository

facebooktwittergoogle_plusredditpinterestlinkedinmail

JMS Serializer: serialize camel-cased fields without them being renamed

Using JMSSerializer (or its bundle) serialized field are renamed by default to the underscore-separated words naming convention. If like me you prefer camel-case naming and you want fields serialized as it, there’s two solutions.

1. Set serialize name for each fields

You can use the @SerializedName annotation, serialized-name XML property or the serialized_name YAML configuration to fix the name that will be used for each fields.

2. Change the whole naming strategy

If like me you don’t want to set the serialized name for each field, you can change the naming strategy by your custom one or the simple IdenticalPropertyNamingStrategy that don’t rename fields.

The first solution is to set the naming strategy while creating your serializer using the SerializerBuilder:

The second solution if you use the bundle is to override the jms_serializer.camel_case_naming_strategy.class parameter in your app/config/parameters.yml file.

facebooktwittergoogle_plusredditpinterestlinkedinmail

Sonata Admin: Create ACL on object created outside of Admin

If you're using Sonata Admin and Symfony's ACL, you can extends Sonata Admin with the CoopTilleulsAclSonataAdminExtensionBundle. Using it, lists just contain data the logged in user has right to view. Thanks to the ACL editor, you can simply manage ACL inside your application and in the Sonata Admin.

It's perfectly working when objects are created inside the Sonata Admin, but don't works when you're creating them in a custom controller. 
To make it working, you just have to create the ACL using the Sonata Admin Security Handler.

Let's imagine you've a controller that is handling a form, and we've like the following code:

Now, you just have to get the sonata.admin.security.handler which is an alias of the current security handler (look at SonataAdminExtension.php#L108) and update ACLs after persisting your model. If your Admin service for this model is named foo.barbundle.admin.model, use the following code:

facebooktwittergoogle_plusredditpinterestlinkedinmail

PHPUnit: MySQL “Too many connections” error

Even if it's the best idea to write tests that need a real database connection, sometimes it's something needed. If you're using Symfony2, you can simply follow the "How to test Doctrine Repositories" part of Symfony documentation to do that.

But if you're running a large amount of tests you'll get the following MySQL error:

SQLSTATE[08004] [1040] Too many connections

This means that you reached the maximum number of simultanous connections (max_connections parameter in my.cnf). To fix that behaviour, I had to change the processIsolation parameter of PHPUnit in the phpunit.xml file, like this:

<phpunit
backupGlobals = "false"
backupStaticAttributes = "false"
colors = "true"
convertErrorsToExceptions = "true"
convertNoticesToExceptions = "true"
convertWarningsToExceptions = "true"
processIsolation = "true"
stopOnFailure = "false"
syntaxCheck = "false"
bootstrap = "bootstrap.php.cache" >

facebooktwittergoogle_plusredditpinterestlinkedinmail

Symfony2 Form, PATCH requests and handleRequest: Form is never valid

From Symfony 2.3 we can use (PR #7849) PATCH requests with the Form component to submit a part of the form which will override the form default values. This is really helpful moreover using FOSRestBundle and its listeners !

With this configuration, to make a user available to PATCH its profile using REST API, you simply have to write this few lines:

But the form is never valid…

In fact, you’ll never have a valid form if you let it as it’s. The problem is that the form is never submitted by the HttpFundationRequestHandler because the current request method (PATCH) isn’t a GET or POST, which are waited by the form (see L39).

Two solutions

You’ve 2 simple solutions, use the submit method, or set the method option on the form.

facebooktwittergoogle_plusredditpinterestlinkedinmail

php-fpm segfault at f6 avec APC

En voulant modifier la configuration d’APC, pour augmenter la taille d’un segment de 30M à 64M, j’ai uniquement modifié la directive apc.shm_size. L’opération m’as valu une erreur de segmentation lors du démarrage de php-fpm.

Je me suis donc mis à la tâche de mettre à jour PHP ainsi que tous ces modules PECL sous Gentoo. Une fois la mise à jour s’étant bien passé, APC est à la version 3.1.9 mais php-fpm refuse toujours de démarrer… J’ai donc remis la valeur de apc.shm_size à 30M et php-fpm s’est très bien lancé.

On peut donc vérifier la taille maximum de mémoire partagée allouée par le système de le fichier /proc/sys/kernel/shmmax :

Par conséquent, on peut voir qu’APC n’a pas pu réserver 64M de mémoire partagée, puisque le système lui refuse. Je déplore un peu le manque de message d’erreur et l’erreur de segmentation qui peut provenir de “nul-part” si l’on configure son système automatiquement.

À ce stade vous avez deux possibilités:
Continue reading php-fpm segfault at f6 avec APC

facebooktwittergoogle_plusredditpinterestlinkedinmail

Symfony2: nom de la route depuis un template Twig

Dans Symfony2, il est possible d’accéder aux propriétés de la requête actuelle à partir d’un template Twig grâce aux variables globales.

En l’occurrence, ça peut être utile pour connaître le nom de la route utilisée. Ainsi, avec la variable app.request, on peut avoir accès aux attributes, et donc à la route utilisée. En PHP, on aurions pu récupérer l’information comme ceci:

Avec Twig, le code deviens ceci:

Une fonctionnalité toute bête mais qui peut s’avérer très pratique!

facebooktwittergoogle_plusredditpinterestlinkedinmail

Symfony 2 et PostgreSQL: Mots réservés

Symfony 2 propose une abstraction des entities très intéressante grâce à Doctrine. Je poste ce petit article car j’ai eu une erreur tout simple:

En fait, j’ai créé un bundle nommé User, et doctrine souhaite donc créer la table User. Le problème, c’est que user est un mot clé réservé dans PostgreSQL. Par conséquent, il faut donc forcer Doctrine à escaper le nom de la table. Pour se faire, il suffit d’ajouter une annotation Table en préfixant et suffixant le nom de la table par .

Voici par exemple ma classe User avant la correction:

Il suffit donc de d'ajouter l'annotation @ORMTable en spécifiant le nom de la table entouré de . Le nouveau code est:

Ainsi, Doctrine va générer ses requêtes en ajoutant des caractères d’échappement sur le nom de la table. Ainsi, vous n’aurez plus d’erreur! :)

facebooktwittergoogle_plusredditpinterestlinkedinmail