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 <[email protected]>: > 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 > [email protected] > Pour résilier votre abonnement envoyez un e-mail à l'adresse > [email protected] > --- > 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 [email protected] Pour résilier votre abonnement envoyez un e-mail à l'adresse [email protected] --- 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 [email protected]. Pour plus d'options, visitez le site https://groups.google.com/d/optout .
