au lieu de sauvegarder tout les x temps, pourquoi tu save pas juste a la db au moment ou le plugin se desactive

C'était marqué dans l'issue

au lieu de sauvegarder tout les x temps, pourquoi tu save pas juste a la db au moment ou le plugin se desactive

C’est déjà fait xd au save() de la feature, donc à la désactivation du plugin, saveAllBalances() flush les balances modifiées

L’autosave est volontaire en plus du shutdown save ça évite de perdre toutes les modifications depuis le démarrage si le serveur crash/kill ou si l’arrêt ne va pas jusqu’au bout. Et il ne sauvegarde pas tous les balances à chaque fois, seulement les UUID marqués dirty depuis la dernière sauvegarde :)

Le serveur n'est pas cense etre kill ou crash, meme il ne sera jamais kill...

Ben après il peut crash oui. Mais il est tjr éteint à 2h donc cv

Même si le serveur n’est pas censé crash il peut crash mdrrrrr l’autosave limite la perte si ça arrive et dans tous les cas le coût en perf est faible on ne save pas tous les comptes seulement les dirty en batch

Tu appelles quoi un compte dirty?

Dirty = modifié depuis le dernier save DB
On garde l’UUID dans dirtyBalances et au prochain save on persiste seulement ces comptes

Le probleme, est que la le lag a lieu lors de la premiere connexion des joeurs, c'est un moment que l'on avait fait avec 50bots de souvenir, et le lag venait du save a la db, donc la si je comprends bien, a un moment, le serveur va lag parcequ'il save toutes les donne dans la db a un moment x

Fin et déjà pour qu'on valide le problème, il faudra que tu donnes un jar de ton plugin, on fait un teste avec 50-100 joueurs, et on attends jusqu'au moment où le scheduler s'exécute pour save la db, et on tentera

Bon @gtolontop, si c'est pour faire du vibecoding sur le projet ce n'est pas la peine de venir faire une PR.

Le satan qui se réveille avec le full vibecoding qui fait mal

Bon @gtolontop, si c'est pour faire du vibecoding sur le projet ce n'est pas la peine de venir faire une PR.

MDRRRRR, elle est vraiment niquel ma PR je vois pas le soucis + c'est pas du vibecoding mais j'avoue que mon code a une vibe très propre :)

Ta mal pris le faite que tu es tort ici ?

ou ici ?

Le satan qui se réveille avec le full vibecoding qui fait mal

Très propre se vibecoding en tous cas

Bon @gtolontop, si c'est pour faire du vibecoding sur le projet ce n'est pas la peine de venir faire une PR.

Dis-moi, qu'aurais-tu fait différemment ?

Donc pourquoi il y a ecris CODEX dans ta PR ....
Ne me prends pas pour un con non plus

Bon @gtolontop, si c'est pour faire du vibecoding sur le projet ce n'est pas la peine de venir faire une PR.

Dis-moi, qu'aurais-tu fait différemment ?

Honnetement, bcp de chose, mais si tu "ne vibecode pas" chaque developpeur fait differemment donc je n'aurais pas fait pareil que toi

Bon @gtolontop, si c'est pour faire du vibecoding sur le projet ce n'est pas la peine de venir faire une PR.

MDRRRRR, elle est vraiment niquel ma PR je vois pas le soucis + c'est pas du vibecoding mais j'avoue que mon code a une vibe très propre :)

Ta mal pris le faite que tu es tort ici ?

ou ici ?

Tu mets tout sur le principe de la raison? Pourquoi ?
Tu as des choses à montrer?
Avoir tort n'est pas négatif le temps que la personne explique pourquoi elle a tort.

On va réfléchir à un débat entre le staff.
Juste je réponds sur un point, les tests ne fail pas a cause des NMS/Dream???? Tu parles bien de la dimension des rêves ?.
Toutes les features utilisant les NMS ne peuvent pas être testée. Et ne sont pas chargée ds les tests.

Bonjour, la PR est-elle prête à être revue ? Je vois qu’elle est encore en draft.

1. Concernant les tests, tu utilises de la réflexion. Ce n’est généralement pas recommandé. Je ne sais pas si Mockito est inclus dans le projet, mais si c’est le cas, ce serait préférable de l’utiliser et de supprimer la réflexion.

2. Est-il possible d’en profiter pour corriger les tests unitaires de l’Economy Manager ? Certains sont actuellement en échec, et comme tu as une PR ouverte dessus, ce serait intéressant de les stabiliser.

3. J’ai également remarqué plusieurs copies en mémoire. Pourquoi ne pas modifier directement l’objet déjà instancié ?

On va réfléchir à un débat entre le staff. Juste je réponds sur un point, les tests ne fail pas a cause des NMS/Dream???? Tu parles bien de la dimension des rêves ?. Toutes les features utilisant les NMS ne peuvent pas être testée. Et ne sont pas chargée ds les tests.

Oui j’ai résumé trop vite xd

sur les tests j'obtiens

• EconomyManagerDirtySaveTest : 2 tests, 0 fail
• EconomyManagerTest : 16 tests, 5 fail

Dans le XML de test, les fails sont :

• testSuccessWithdrawBalance() -> DreamSteps fail à l’init parce que DreamDimensionManager.DREAM_WORLD est null.
• les 4 tests avec transactions/reason -> NoClassDefFoundError: net/minecraft/network/protocol/Packet, déclenché via ContestManager.initPhase3.

Donc quand j’ai dit Dream/NMS, je parlais de ces causes-là, mais j'essaierais d'être plus précis directement les prochaines fois

On va réfléchir à un débat entre le staff. Juste je réponds sur un point, les tests ne fail pas a cause des NMS/Dream???? Tu parles bien de la dimension des rêves ?. Toutes les features utilisant les NMS ne peuvent pas être testée. Et ne sont pas chargée ds les tests.

Oui j’ai résumé trop vite xd

sur les tests j'obtiens

• EconomyManagerDirtySaveTest : 2 tests, 0 fail
• EconomyManagerTest : 16 tests, 5 fail

Dans le XML de test, les fails sont :

• testSuccessWithdrawBalance() -> DreamSteps fail à l’init parce que DreamDimensionManager.DREAM_WORLD est null.
• les 4 tests avec transactions/reason -> NoClassDefFoundError: net/minecraft/network/protocol/Packet, déclenché via ContestManager.initPhase3.

Donc quand j’ai dit Dream/NMS, je parlais de ces causes-là, mais j'essaierais d'être plus précis directement les prochaines fois

Tkt je préfère que tu me demandes des choses comme cela a la place de l'IA qui te résume mais qui sait pas vrm 👍

On va réfléchir à un débat entre le staff. Juste je réponds sur un point, les tests ne fail pas a cause des NMS/Dream???? Tu parles bien de la dimension des rêves ?. Toutes les features utilisant les NMS ne peuvent pas être testée. Et ne sont pas chargée ds les tests.

Oui j’ai résumé trop vite xd

sur les tests j'obtiens

• EconomyManagerDirtySaveTest : 2 tests, 0 fail
• EconomyManagerTest : 16 tests, 5 fail

Dans le XML de test, les fails sont :

• testSuccessWithdrawBalance() -> DreamSteps fail à l’init parce que DreamDimensionManager.DREAM_WORLD est null.
• les 4 tests avec transactions/reason -> NoClassDefFoundError: net/minecraft/network/protocol/Packet, déclenché via ContestManager.initPhase3.

Donc quand j’ai dit Dream/NMS, je parlais de ces causes-là, mais j'essaierais d'être plus précis directement les prochaines fois

Tu vois je savais pas que ça crash a cause de la dimension des rêves j'avais pas check et le problème c'est les transactions en async qui fail tt

Bonjour, la PR est-elle prête à être revue ? Je vois qu’elle est encore en draft.

1. Concernant les tests, tu utilises de la réflexion. Ce n’est généralement pas recommandé. Je ne sais pas si Mockito est inclus dans le projet, mais si c’est le cas, ce serait préférable de l’utiliser et de supprimer la réflexion.
2. Est-il possible d’en profiter pour corriger les tests unitaires de l’Economy Manager ? Certains sont actuellement en échec, et comme tu as une PR ouverte dessus, ce serait intéressant de les stabiliser.
3. J’ai également remarqué plusieurs copies en mémoire. Pourquoi ne pas modifier directement l’objet déjà instancié ?

Bonjour, elle est encore en draft justement parce que je préfère traiter les retours avant de la passer ready.

Pour la réflexion dans les tests je comprends se que tu dis mais j’ai vérifié, Mockito n'est pas dans les dépendances du projet. Je peux soit ajouter Mockito si vous êtes ok avec ça, soit refactorer le test / la logique pour éviter la réflexion.

Pour les tests EconomyManagerTest, oui je peux regarder pour les stabiliser. Actuellement, sur mon run local, les nouveaux tests isolés EconomyManagerDirtySaveTest passent, mais EconomyManagerTest a encore 5 fails liés au chargement global du plugin / scheduler lancé pendant MockBukkit.

Pour les copies mémoire elles sont là pour éviter qu’un objet mutable récupéré depuis l’API soit modifié sans passer par le dirty tracking. par exemple si getPlayerBank() retourne l’objet live, un appelant peut faire deposit() dessus sans marquer l’UUID dirty. Les copies évitent ça. Après, si vous préférez une autre approche côté API, je peux adapter.

On va réfléchir à un débat entre le staff. Juste je réponds sur un point, les tests ne fail pas a cause des NMS/Dream???? Tu parles bien de la dimension des rêves ?. Toutes les features utilisant les NMS ne peuvent pas être testée. Et ne sont pas chargée ds les tests.

Oui j’ai résumé trop vite xd
sur les tests j'obtiens

• EconomyManagerDirtySaveTest : 2 tests, 0 fail
• EconomyManagerTest : 16 tests, 5 fail

Dans le XML de test, les fails sont :

• testSuccessWithdrawBalance() -> DreamSteps fail à l’init parce que DreamDimensionManager.DREAM_WORLD est null.
• les 4 tests avec transactions/reason -> NoClassDefFoundError: net/minecraft/network/protocol/Packet, déclenché via ContestManager.initPhase3.

Donc quand j’ai dit Dream/NMS, je parlais de ces causes-là, mais j'essaierais d'être plus précis directement les prochaines fois

Tkt je préfère que tu me demandes des choses comme cela a la place de l'IA qui te résume mais qui sait pas vrm 👍

J'avais bien run les tests juste j'avais pas pensé a te remonter exactement les tests xd

On va réfléchir à un débat entre le staff. Juste je réponds sur un point, les tests ne fail pas a cause des NMS/Dream???? Tu parles bien de la dimension des rêves ?. Toutes les features utilisant les NMS ne peuvent pas être testée. Et ne sont pas chargée ds les tests.

Oui j’ai résumé trop vite xd
sur les tests j'obtiens

• EconomyManagerDirtySaveTest : 2 tests, 0 fail
• EconomyManagerTest : 16 tests, 5 fail

Dans le XML de test, les fails sont :

• testSuccessWithdrawBalance() -> DreamSteps fail à l’init parce que DreamDimensionManager.DREAM_WORLD est null.
• les 4 tests avec transactions/reason -> NoClassDefFoundError: net/minecraft/network/protocol/Packet, déclenché via ContestManager.initPhase3.

Donc quand j’ai dit Dream/NMS, je parlais de ces causes-là, mais j'essaierais d'être plus précis directement les prochaines fois

Tu vois je savais pas que ça crash a cause de la dimension des rêves j'avais pas check et le problème c'est les transactions en async qui fail tt

Si tu fais une issue je pourrais regarder :)

Si tu fais une issue je pourrais regarder :)

Tu peux la faire aussi, elle sera validé tkt pas

Si tu fais une issue je pourrais regarder :)

Tu peux la faire aussi, elle sera validé tkt pas

Tu veux que je commit sur la même PR ?

Généralement, tu dois ouvrir ta PR pour qu'on sache qu'on peut review. Fait comme cela, sinon il risque d'avoir des oublis

Si tu fais une issue je pourrais regarder :)

Tu peux la faire aussi, elle sera validé tkt pas

Tu veux que je commit sur la même PR ?

De fixer les tests? Fait en une autre

Généralement, tu dois ouvrir ta PR pour qu'on sache qu'on peut review. Fait comme cela, sinon il risque d'avoir des oublis

ne t'étonne pas si ta PR ne se fait pas review.

Bonjour, elle est encore en draft justement parce que je préfère traiter les retours avant de la passer ready.

Pour la réflexion dans les tests je comprends se que tu dis mais j’ai vérifié, Mockito n'est pas dans les dépendances du projet. Je peux soit ajouter Mockito si vous êtes ok avec ça, soit refactorer le test / la logique pour éviter la réflexion.

Pour les tests EconomyManagerTest, oui je peux regarder pour les stabiliser. Actuellement, sur mon run local, les nouveaux tests isolés EconomyManagerDirtySaveTest passent, mais EconomyManagerTest a encore 5 fails liés au chargement global du plugin / scheduler lancé pendant MockBukkit.

Pour les copies mémoire elles sont là pour éviter qu’un objet mutable récupéré depuis l’API soit modifié sans passer par le dirty tracking. par exemple si getPlayerBank() retourne l’objet live, un appelant peut faire deposit() dessus sans marquer l’UUID dirty. Les copies évitent ça. Après, si vous préférez une autre approche côté API, je peux adapter.

Bonjour,

Il est préférable de passer la PR en ready si vous jugez qu’elle est prête pour la production. Étant donné que nous ne sommes pas nombreux à maintenir le projet, nous nous concentrons principalement sur celles qui sont en ready afin de fournir des retours.

Concernant la réflexion, il serait préférable de la retirer, mais sans utiliser Mockito. Cela fera l’objet d’une autre PR.
Pour les tests oubliés, j’avais peur que les échecs actuels soient causés par cette PR, mais après vérification, cela ne semble pas être le cas.

Concernant le clone, je laisse @PuppyTransGirl vérifier et nous donner son avis afin d’en discuter. De mon côté, je ne suis pas particulièrement favorable.

Généralement, tu dois ouvrir ta PR pour qu'on sache qu'on peut review. Fait comme cela, sinon il risque d'avoir des oublis

ne t'étonne pas si ta PR ne se fait pas review.

Elle est déjà ouverte la PR ? J'ai pas compris

Elle est déjà ouverte la PR ? J'ai pas compris

Elle n'est pas en ready for review, elle est en draft

Il est préférable de passer la PR en ready si vous jugez qu’elle est prête pour la production. Étant donné que nous ne sommes pas nombreux à maintenir le projet, nous nous concentrons principalement sur celles qui sont en ready afin de fournir des retours.

C'est bon :)

Concernant la réflexion, il serait préférable de la retirer, mais sans utiliser Mockito. Cela fera l’objet d’une autre PR. Pour les tests oubliés, j’avais peur que les échecs actuels soient causés par cette PR, mais après vérification, cela ne semble pas être le cas.

Pourquoi faudrait-il la retirer si c'est correct et que ça fonctionne bien ? Et ça n'utilise déjà pas Mockito.