Reprise du message précédent :

TP Link aussi ca marche super

et en général je modélise tous les booléen par des dates en base maintenant ( et dans mon état en général)
 
isxxx devient donc une verif que la base ne soit pas vide

La seconde donne la possibilité de matérialiser des états pas nécessairement logiques, genre le client a consenti sans avoir répondu (après ça peut aussi être une modélisation qui a du sens selon les juridictions, tu peux avoir des clients qui dont en opt-in et d’autres en opt-out, dans ce cas il peut être logique de modéliser les informations indépendamment, mais un système à 3 états qui résout séparément le défaut me semble plus approprié).

LOL je vois que je n'aurai pas le choix.
Ca promet, vu comment je tolère les alcools forts.

Avec un peu de chance, tout l'alcool s'est déjà évaporé par le bouchon (ou c'est devenu di vinaigre )

 
ok sur le cas des états, mettre 25 flags pour un machin à 25 états, c'est complètement con (et écrire les "isXXX()" aussi selon moi : si tu t'es fait chier à écrire une Enum dans ton code, c'est pas pour répéter ta nomenclature d'états sous forme de méthodes dans une classe à côté, et même pour les états à caractéristiques communes (genre tu as 12 états d'erreur, et tu veux un "isError" ), bah les Enums Java permettent de faire ça proprement)
 
 
Modéliser les trucs à 2 états pour y associer une sémantique, pourquoi pas mais tu vas soit rapidement te retrouver avec une palanquée d'Enums un peu pourries à 2 états et une duplication de sémantique entre les noms des enums et le nom des attributs /colonnes qui les portent (ou alors tu adaptes ta modélisation pour faire un bag ou un truc comme ça), soit te retrouver avec 12 enums simples à 2 valeurs, que tu sera tenté de réutiliser (surtout si tu bosses avec Davy "le copier/colller c'est INTERDIT" ), dans des contextes métiers qui pourront diverger par la suite.
 
bref, on peut discuter du point, mais pas comme il a l'intention de faire (ie : en mode "c'est teeeeeellement evident, je devrais pas avoir à m'abaisser à l'expliquer" ), surtout dans un contexte avec un gros legacy qui n'applique pas DU TOUT le principe.

 
ah ben si tu fais du DDD (c'est l'objectif), tu utilises le vocabulaire des spécialistes métier.
 
Le problème dans le contexte, c'est qu'ils ont pas tous le même

Pour moi le boolean c'est true/false et basta,  
Si tu as 3 états, ben dans ce cas tu fous une Enum avec les 3 valeurs dont tu as besoin : true, false, "not answered"

 
TP-Link  

+1 : hasConsented
 

 
c'est pas un peu premature optimisation comme discussion ? comme a priori on sait pas si on va rester sur 2 états ou plus dans le futur, on peut commencer avec un boolean, et passer sur une enum plus tard ?
Sinon pour l'exemple donné, je préfère 100x un système qui me donne un isPersonEligible() qui checke si la personne a 1/ répondu 2/ consenti, comme ça je peux consommer les données sans avoir à connaître tout le fonctionnel interne de la base (le domaine dans lequel je bosse à l'heure actuelle a pas fait ça, donc on se retrouve avec 50 shades of "eligible", parce que personne le calcule pareil)

Et pour les switchs, il me faudrait un 16 ports rackable en baie 10 pouces, ou qui fasse moins de 25 cm de large

Complètement

Pour moi c'est ça la vraie question : l'implémentation de persistance et de calcul à la limite je m'en branle complètement : si tu veux l'optimiser pour Oracle, MAchin ou truc, je m'en fous. Par contre les méthodes exposées par ton modèle, ça m'"intéresse. Et là oui, soit tu exposes une Enum ou un boolean mais pas un truc chelou qui peut laisser place à l'interprétation.

Je confirme qu'ici, en Autriche, le pass vaccinal ou un test PCR tout frais sont demandés presque partout où je vais (hôtels, musées, restaus, cafés si on s'assoit). Après personne n'a jamais vérifié l'authenticité du code QR. Je ne sais pas s'il y a une app de lecture pour vérification de pass sanitaire, mais si elle existe, ils ne l'ont pas et se contentent d'une vérif visuelle. Une seule fois, une pièce d'identité a été demandée en sus. Donc la triche est aisée, mais bon, les Allemands et les Autrichiens sont des gens disciplinés. En France, par contre...

En fait c'est surtout que si tu te fais choper à gruger en Allemagne tu prends très cher. Du coup y'a moins de monde à vouloir jouer avzc le système.
La discipline c'est pas génétique  

C'est Michael Scott, en fait, ce type.

C’est pas parce-que tu as une modélisation interne que tu veux l’exposer, ou que les clients en on quoi que ce soit à foutre (souvent ils veulent des prédicats simples).
 
C’est pas différent d’exposer des getters pour tes champs
 

Tu vas te retrouver avec une nomenclature cohérente à travers tes couches et… c’est pas bien?
 

Pas plus qu’avec n’importe quel autre typage fin. Mais clairement avoir un langage où t’as pas besoin de tout écrire en triplicat pour définir un type aide. C’est probablement pas en java que j’irais faire ce genre de choses.

Sure.
 

Pour moi c’est exactement l’inverse, le booléen est une optimisation au détriment de la modélisation.

meme combat, j'ai eu plein de matos des 3, tous les 3 tres bon

Je pense que ça se défend comme ci: le boolean modélise le résultat d'une comparaison de valeurs. Donc ce qu'on ne devrait garder, ce sont les valeurs, qui ont un sens fonctionnel, et non le boolean, qui n'en a pas (vrai ou faux n'ont pas de sens fonctionnel en soi).

Autrement dit, pour reprendre l'exemple de gfive, on ne devrait stocker que les valeurs:
"a donné son consentement"
"n'a pas donné son contentement"

et "a répondu"/"n'a pas répondu"

Sachant qu'un booléen est de toute façon stocké comme un short, techniquement, je pense que ça se défend. Mais bon, comme dit gfive, on se retrouve à multiplier les Enums, et ça obscurcit le code, c'est moche. Mais bon ça se limite à la couche de persistence, donc c'est quand même supportable.

Ca n'empêche pas que le mec qui te sort qu'il a 8000 pages d'archi dans la tête, t'as quand même envie de lui répondre "n'hésite pas à écrire une encyclopédie".

ex-pote

J'ai plus souvent vu cet argument pour des APIs et des paramètres de méthode mais oui c'est la même mayonnaise.
Quand t'as un updateInvoice(invoice, false, true) dans ton code, c'est pas exactement aussi explicite que updateInvoice(invoice, DO_NOT_NOTIFY-_CUSTOMER, ARCHIVE_OLD_VERSION).

quoi ???
C'est le changement d'état que tu colles en base ?

je stocke la date du changement au lieu de stocker le fait que ça ait changé

 
J'avoue, je pige pas
 
tu sais quand ça a été mis à true, mais tu peux pas savoir quand ça a été remis à false, donc ça me semble pas avoir un grand intérêt.
 
Après je me demande si Flo ne trolle pas

non, non réellement

effectivement, ça ne permet pas de  suivre false -> true -> false -> .... mais ça aide pour l'exploitation des données  ou pour des rollback
https://changelog.com/posts/you-mig [...] mestamp-it

C’est généralement pour des changement monotoniques, ou pour lesquels le reset est sans importance.  
 
Genre « le colis a été livré », savoir quand c’est fait est utile donc dupliquer l’info est con autant juste stocker la date, et si c’était une erreur l’information de restauration est pas intéressante.  
 
Si au final la date te sert jamais il est beaucoup plus facile de convertir tes dates en booléens (et de garder un résultat cohérent) que l’inverse.
 
Après ça vaut pas avoir des tables temporelles par défaut. C’est l’un des trucs qui manquent à postgres.

 
ok, soit.
 

 
ok, mais alors j'appelle pas ça un booléen perso.
 
Pour moi t'es dans le cas où tu stockes une date de livraison (que tu peux consulter en tant que telle   ), et où tu as une méthode qui exploite la date pour dire si c'est livré ou pas.

Tu confonds idée et exemple.  
 
L’idée c’est que si tu stocke un booléen relativement monotonique t’as beaucoup à gagner et peu à perdre à toujours utiliser un timestamp à la place.

 
ok, effectivement.
 
Mais là tu mets Davy en PLS je pense

Sauf si tu n'en as rien à faire de la valeur du booléen (ce qui est peu probable), c'est suicidaire, comme approche. La perte d'une seule valeur et tu perds tous les états suivants. Et si tu veux la valeur du n-ième état tu dois lire les faire un count des N dates menant à l'état à la date t.
 
Bon sinon, à côté de moi, j'ai un type de 60 ans en culotte de peau qui écoute sur son tel du yodelling accompagné de bal musette remis à la sauce techno. Tuez-moi.

probable, mais est ce que ça ne joue pas en faveur  ?  
 

hein?  
mais ton boleen aussi ne stocke que le dernier état

 
Chez les allemands, il y a énormément d'anti-vaccins en ce moment, ça fait très très peur... La plupart du temps (mais pas toujours), ce sont des ultra écolos, aussi die Linke, des neo-nazis, et tout un courant qu'on appelle les "alternatifs" où tu trouves un peu de tout et surtout bcp de n'importe quoi. Malheureusement, c'est encore pire qu'en France.

Si tu ne le persistes pas. On parle bien de persistance, non ?

@elmuch, Flo ne stocke qu'une valeur, qui est la date du dernier passage du booléen à true.
 

Vu vos discussions, je me demande pourquoi le Davy en question n'a pas encore proposé une blockchain.

Oui mais comme tu dis, ce cas d'utilisation, où la transition ne peut se faire que dans un seul sens, n'est pas celui d'un booléen. Flo dit que la transition peut se faire dans les 2 sens. Ou alors j'ai encore mal compris

Ou tu as un code style qui dit que tes booléens doivent être commentés
updateInvoice(invoice, /*notify_customer*/ false, /*archive_old*/ true)

Vous êtes vraiment en train de batailler sur le fait qu'un booleen est simplement un enum à deux valeurs?

Tp link est au dessus pour moi

 
+1 deleted_at plutôt que is_deleted (sauf énorme problématique de perfs / stockage)

Moi vous lisant polémiquer sur les booléens toute la matinée alors que je stocke les miens sur 1 bit : has science gone too far?

Saperlipopette.. Si qqun trouve un genre de spec OpenApi ou au moins une description des types pour cette API, HArko l'épouse!
 
https://docs.bmc.com/docs/ars2102/o [...] 20632.html

Ce niveau de pas-rest pour une api taggée rest ils documentent littéralement pas les schémas de sortie
 
Edit: ça a l’air d’être un truc de création de bidules custo donc tes sorties vont probablement dépendre vachement de ton setup. Il y a une api java à côté aussi ça peut ptet guider. Et les sorties font référence à des entrées donc les structures sont probablement similaires (et peu structurées / très génériques).

"deleted_at" ou "deleted_on" ?  
J'arrive jamais à me décider