Merci pour les details, tu as raison pour les histoires de noms de methodes
mais:
1) les nouveaux jobs sont dans un namespace a part (qui contient tout le
code reecrit, services, serializers ...). Ca simplifie quand meme pas mal
les choses.
2) perform_async / perform_later -> un petit monkey patch a base d'alias ca
fait pas le taff?
En ce qui concerne le parser, sidekiq uniqu job (qui veut dire que
quelqu'un a foire a un moment ou un autre), les solutions maisons niquees
pour tenter de gerer l'ordre des jobs et sidetiq rendent la migration
complexe sans avoir a repenser pas mal d'entre eux.
2016-09-20 16:55 GMT+08:00 Olivier El Mekki :
> Hello,
>
> Je laisse d'autres te répondre sur la possibilité de cohabitation, chaque
> fois que j'ai été confronté à ce problème, j'ai choisi soit de rester sur
> le low level, soit de migrer entièrement sur activejob.
>
> Une mise en garde cela dit : une solution mixte me semble peu efficace si
> l'objectif est de réduire la dette technique. Si tu utilise à la fois
> activejob et sidekiq directement, chaque fois qu'un développeur voudra
> utiliser un job, il devra se demander : "alors, ce job là, est-ce que je
> dois appeler `performer_later` ou `perform_async`, dessus?". Vous allez
> vous faire maudire :)
>
> Les changements au niveau fichiers de job pour passer de sidekiq à
> activejob sont minimes, retirer un include et ajouter un héritage,
> éventuellement gérer les sidekiq options s'il y en a. Est-ce qu'il n'est
> pas envisageable d'écrire un parser pour modifier vos fichiers de job?
>
>
> On Tuesday, September 20, 2016 at 9:59:12 AM UTC+2, Florian Dutey wrote:
>>
>> Bonjour a tous,
>>
>> J'ai un petit dilemme qui n'a malheureusement pas trouve de reponse dans
>> google.
>> Nous avons migre sur rails 4 il y a 1 ans 1/2. Rails 4 qui apporte
>> ActiveJobs. Nous avons deja une liste de jobs longue comme le bras (un tres
>> long bras) donc nous n'avons pas migre les jobs existants et avons continue
>> a proceder comme avant.
>>
>> En ce moment, nous deployons beaucoup d'energie a virer les milliards de
>> tonnes de dettes techniques et introduire des bonnes pratiques. ActiveJob
>> semble etre une meilleure solution sur le long terme que des "pure sidekiq
>> jobs" puisque ca permet de s'abstraire du backend et d'en changer quand bon
>> nous semble (si bon nous semble).
>>
>> Probleme: nous ne pouvons pas migrer tous les jobs d'un coup. Il y en a
>> beaucoup trop.
>> Question: Est-ce qu'il est possible d'avoir ActiveJob (avec sidekiq comme
>> backend) ET des jobs sidekiq purs qui tournent en meme temps?
>>
>> Malgre de longues heures a chercher sur google, je n'ai vu personne qui
>> parlait de ce probleme.
>>
>> Merci d'avance ;)
>>
>> Flo
>>
> --
> --
> Vous avez reçu ce message, car vous êtes abonné au groupe "Railsfrance" de
> Google Groups.
> Pour transmettre des messages à ce groupe, envoyez un e-mail à l'adresse
> railsfrance@googlegroups.com
> Pour résilier votre abonnement envoyez un e-mail à l'adresse
> railsfrance-unsubscr...@googlegroups.com
> ---
> Vous recevez ce message, car vous êtes abonné au groupe Google Groupes
> "Railsfrance".
> Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le
> concernant, envoyez un e-mail à l'adresse railsfrance+unsubscribe@
> googlegroups.com.
> Pour obtenir davantage d'options, consultez la page
> https://groups.google.com/d/optout.
>
--
--
Vous avez reçu ce message, car vous êtes abonné au groupe "Railsfrance" de
Google Groups.
Pour transmettre des messages à ce groupe, envoyez un e-mail à l'adresse
railsfrance@googlegroups.com
Pour résilier votre abonnement envoyez un e-mail à l'adresse
railsfrance-unsubscr...@googlegroups.com
---
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes
Railsfrance.
Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant,
envoyez un e-mail à l'adresse railsfrance+unsubscr...@googlegroups.com.
Pour plus d'options, visitez le site https://groups.google.com/d/optout .
