Produits Entr'ouvert » w.c.s.

Il me semble que le premier et nouveau Evolution.__init__ est écrasé par le deuxième (j'ai juste regarder le patch vite fait).

Je n'aime pas trop la multiplication des getter/setter, sur un tas d'attributs qui ne peuvent pas bouger.

Par contre, parts est une liste dont le contenu peut bouger, et le getter/setter va passer à côté de ça.

Je serais pour une approche moins technique et plutôt analyser ce qui peut effectivement bouger sur un objet Evolution (sans regarder je dirais que ça concerne juste last_jump_datetime et le contenu de parts).

Je serais pour une approche moins technique et plutôt analyser ce qui peut effectivement bouger sur un objet Evolution (sans regarder je dirais que ça concerne juste last_jump_datetime et le contenu de parts).

Et noter que ce sera toujours le dernier evolution qui sera modifié, jamais les précédents, et peut-être que juste se baser là-dessus serait totalement satisfaisant.

J'ai l'impression qu'on peut plus simplement :

+            # iterate in reverse order to only save new and last evolution
+            for evo in reversed(self._evolution):
...
-                evo._sql_id = cur.fetchone()[0]
+                if hasattr(evo, '_sql_id'):
+                    break
+                else:
+                    evo._sql_id = cur.fetchone()[0]

Frédéric Péters a écrit :

J'ai l'impression qu'on peut plus simplement :

[...]

Moi aussi j'y ai cru... mais dans ce cas les id ne seront plus séquentiels. Je n'ai donc pas voulu casser cette supposition (qui, je crois, est testée dans un test unitaire)

Moi aussi j'y ai cru... mais dans ce cas les id ne seront plus séquentiels. Je n'ai donc pas voulu casser cette supposition (qui, je crois, est testée dans un test unitaire)

Ok, ça me semble quelque chose qui mérite d'être changé, je vois hors tests, l'ORDER BY devrait vraiment être adapté.

        sql_statement = (
            '''SELECT id, who, status, time, last_jump_datetime,
                                  comment, parts FROM %s_evolutions
                            WHERE formdata_id = %%(id)s
                         ORDER BY id'''
            % self._table_name
        )

et peut-être d'autres.

Le champ time des objets evolution n'est précis (côté python) qu'à la seconde. Du coup en cas d'insertion de plusieurs objets créés sur un intervalle court, on ne pourra pas trier avec ce seul critère, il faudra un autre critère pour les distinguer.
Actuellement, sur la base de test, j'ai trouvé sans difficultés une table evolution où on a deux objets evolutions pour le même formdata et le même time.

Ok, on ne se lance pas là-dedans du coup; je serais quand même pour revoir le patch, pas fan du for i in range(len(self._evolution) - 1, -1, -1):, plutôt pour quelque chose type,

            for idx, evo in enumerate(self._evolution):
                if not hasattr(evo, '_sql_id'):
                    break
            for evo in self._evolution[idx:]:
                # le code actuel

(qui ne doit pas être correct, c'est pour l'idée)

Sur une semaine, le volume de WAL a été divisé par deux en recette.

Automatic expiration