Reprise du message précédent :
 

http://www.reddit.com/r/KitchenCon [...] well_from/
 

 
ils l'air super casse burnes pour accorder des prêts ... j'ai un pote qui vient de se faire refuser son dossier parce qu'il a pas d'apport (il veut pas en mettre).

 
bah on est plus en 2005, hein!
 
Non, mais en ce qui nous concerne, je pige vraiment pas la raison.. Parce que bon, la maison vaut largement plus que ce qu'il reste à rembourser, on est à 27% d'endettement.. Mais bon, tant pis pour eux, hein

je l'ai déjà dit, ils ont autre à chose à foutre que de vérifier tes dires en faisant venir un expert chez toi. Eux ils font un dossier, le passent à la moulinette informatique et disent oui ou non.

Nan, mais j'ai compris, mais je persiste à penser que c'est con de leur part : entre le non catégorique parce que l'un des deux prêts n'entre pas dans la bonne case, et la constitution de dossier qui veut que tu envoies 50 Mo de docs, DONT une estimation de la valeur du bien (obligatoire pour les dossiers de rachat)  je trouve que le filtre est pas super malin, quoi.

 
On parle de gens qui n'ont jamais eu à faire aucun effort pour gagner de la thune hein.
Ils vont pas commencer maintenant.

come back from the dead  

LUTAIN J4AIME PAS HIBERNATE.
 
mais alors pas, quoi.
 
et j'aime encore moins les idées à la con de mon collègue qui prétend que "oui, spas grave si le modèle objet est pourri et permet de faire des choses qui n'ont aucun sens, dans la mesure où le modèle DB est le plus simple possible"
 
En gros, il refuse qu'on fasse des héritages sur des entités et/ou qu'on stocke une entité sur plusieurs tables.
 
Je manque d'expérience sur ce sujet : y'en a qui en auraient qui pourraient m'expliquer si c'est une position dogmatique à la con, ou si ça a du sens?

ils sont gratuit et offrent des bon taux justement parcequ'ils évitent un maximum d'emmerdes

Pour moi, ça indique un gars qui n'a pas compris que le plus important, ce sont les données. Pas les objets.
Tes données pourront être utilisées par d'autres soft. De quand date la dernière réutilisation d'un objet fait maison ?

https://github.com/Traumflug/Visola [...] .java#L184  

ça vous parait possible comme code ça ? c'est du multi-tache et c'est une autre tâche qui détruit les entrées du keyset ? au fil de l'ajout dans le paths ?

Non, mes données ne pourront pas être utilisées par un autre soft, en l'occurence. Mais alors, pas du tout, hein : c'est la modélisation de l'organisation d'un contenu, y'a aucune chance que ça soit jamais utilisé ailleurs (la DB ne contient pas le contenu, juste l'organisation des modules, l'appli affiche les modules)

Moi, ce que je comprends pas, c'est qu'il est prêt à pondre des modèles objets tordus, sans polymorphisme, ou avec des attributs qui ne veulent rien dire, avec des redondances partout, plutôt que de se faire un peu chier la bite à explorer ce que permet l'ORM au delà du bête "une table = une entité"

Parce qu'au final, les développeurs ils vont travailler avec la modélisation objet, pas avec les tables.

Du coup, on rajoute une couche d'abstraction (notre modèle objet pensé en objet), et un mapping entre les deux. Je trouve ça con

Je vais sans doute dire une connerie mais t'as pas peur d'avoir le temps de faire next() après le dernier élément avant que le set soit empty ?

c'est pas mon code, j'en sais rien, j'ai l'impression que c'est pas du code mort (ou alors la chaine d'appels morts est relativement longue, j'ai pas fait tourner le debugger), mais j'ai l'impression que c'est du code un peu chelou quand même.

Attention pour ça, ça peut vite te retourner dans la figure. On a eu le cas chez nous avec Django, on avait 2 modèles distincts qui partageaient des attributs en communs, du coup on s'est dit que ça pourrait être pas mal d'utiliser le système d'héritage de Django. Du coup on avait une table A pour les attributs communs et une table B et C pour  les champs spécifiques aux modèles B & C, avec une jolie FK en 1-1 pour lier les deux.

Ca a très bien marché et c'était très propre au début... Sauf que quand le volume de donnée à commencer à augmenter, il s'est vite retrouver à faire des JOIN entre A/B ou A/C en permanence, ce qui est de suite moins sympathique quand on parle en millions de lignes, parce qu'au final on avait quasi tout le temps besoin d'attributs communs ET spécifiques en même temps.

( NB : Je sais que Django permet de faire de l'héritage via les Abstract model qui ne présenterait pas ce problème, mais c'est pas le choix qui avait été fait a l'époque )

 
J'imagine que c'est pas idéal dans tous les cas, oui.
 
Mais en l'occurence, c'est une description de portail d'entreprise, il va pas y avoir plus d'une centaine d'items en tout, donc on s'en fout.
 
Et j'ai quand même des tables d'association sur lesquelles je vais devoir faire des jointures, hein. Sauf que je vais devoir me les coder à la main, parce que "ouais, c'est plus simple".

débarquement certain, mais  
http://www.youtube.com/watch?v=dRB-woVjlFY

meme avec procuration ?

Fake ou pas fake?
 
http://www.slate.com/blogs/the_sla [...] lo_ho.html

C'est pas plutôt paths.add qui détruit l'entrée qu'on lui a donnée en entrée ?

le paths, c'est un truc standard de la lib, donc en lui-même il peut pas faire de trucs chelous.
Je pense qu'il y a un lurker sur le paths qui fait delete, mais, c'est louche parce que pendant ce temps le bout de code que je montre continuer à envoyer en boucle toujours la même entrée dans la linkedlist. Le tout sans la moindre structure de synchronisation, ou le moindre truc atomique ni rien qui fasse penser à du multitaches.

Ben il y a bien quelqu'un quelque part qui fait le boulot dans l'affaire ?

pas encore trouvé, tout le code est imbitable

 
C'est quoi ses arguments contre ça ? Ils sont généraux, ou spécifiques à votre schéma ? Il a peur pour l'intégrité des données ou il pense simplement que l'héritage en DB ça marche pas ?
Selon la stratégie d'héritage choisie (STI, Table per Class ou Joined) et la nature de tes données, y'a des cas pas franchement triviaux qui peuvent se produire. Pour un cas bien particulier (une sombre histoire de collections et de clés étrangères) j'en étais arrivé à faire de la composition avec des @Embeddable plutôt que de l'héritage simple.
 

Pas mieux...

Ca fait longtemps que j'ai pas fait de java : iterator() renvoie toujours le même objet, ou il instancie un nouvel iterator à chaque appel ?

nouvel itérateur, obligatoire, pour re-partir à "zéro".

J'en ai pas trop discuté parce que j'ai pas trop le temps et qu'il monte vite dans les tours dès qu'on lui demande d'argumenter un peu ses positions, mais c'est général.

En gros : (extrait d'un de ses articles wiki à destination des devs)

Mais qund tu discutes un peu, tu tombes jamais dans les cas où l'héritage pourrait être une option

Et t'as l'impression que le code marche ? Parce que là au pire tu lances le bouzin il construit le path puis reste dans sa boucle sans fin, tu interromps le processus quand tu en as marre et il manque juste à exécuter lockCrossingNodes optimizePaths et model.setPaths. Je veux dire, ça se trouve c'est utilisé comme ça

(Sauf que lock et optimize sont privées et ne sont appelées que là, du coup ça marche pas... Mais concrètement ça a l'air de fonctionner le machin ou pas ?)

globalement l'appli marche mais comme je l'ai dit, ça veut pas dire qu'elle passe dans cette branche.

 
Là je comprend pas. Dans son speech, j'ai l'impression que passer par un ORM impose la gestion des contraintes de DB par l'ORM. Si tu arrives à lui faire cracher un exemple concret d'héritage qui fout en l'air "la maîtrise du schéma de la DB", je prend, mais son argumentation à l'air fuckée
 

Bon, je suis vraiment une burne en hibernate.
 
Voilà le cas:  
 
Table ITEMS avec les colonnes Id, Name, type, parent (qui est un des ids de ITEMS)
Table INSTANCES avec les colonnes Id, Context, App, Module, Name
 
Table WIN_INSTANCE avec les colonnes winId (FK sur ITEMS.Id) et  instanceId (FK sur INSTANCES.id), où on peut avoir plusieurs lignes pour un seul INSTANCE.id
 
En réalité, mon modèle objet c'est un classe Item, et 3 sous-classes (Site, Page, Window), discriminé par la colonne Type.
 
La classe Window contient une référence à une Instance (table INSTANCES)
 
Avec sa solution, je fais une classe d'entité par table, et je mappe ce bordel sur mon modèle objet. Ca commence à devenir moins drôle quand on efface une ligne de ITEMS dont l'ID est présent dans WIN_INSTANCE : soit je supprime la ligne dans WIN_INSTANCE avant, soit je modélise l'association pour bénéficier de la cascade.. Mais ça me fait super chier, parce que je suis obligé d'avoir un attribut dans la classe Item, qui n'a rien à foutre là, parce que ça n'a pas de sens.
 
Moi, je veux qu'hibernate me crache une liste d'Item directement, dont le type concret sera Window/Page ou Site en fonction de Type, et quand c'est une Window, ça va en plus me chercher la référence à mon instance dans ma table d'association.
 
Mais il dit que c'esty trop compliqué

 
Du coup je dois rater quelque chose, parce que là c'est vraiment le cas d'école/tuto
C'est de la STI toute simple avec une many-to-many, je peux te paster un bout de code demain si tu veux, mais c'est trivial donc j'ai peur que t'en tires pas grand chose. T'as pas plus de détail que "trop compliqué" ?
 

Bcp de choses on été repompées/adaptées/portées de Solaris vers Linux, y'a moyen de vraiment tracer très finement, sous Linux, aussi
 
J'ai l'impression que la migration depuis Solaris, a vraiment été faite à l'économie, sans passer par un minimum de formation pour les admin sys Solaris
 
Vous avez pas une "vraie" compétence Linux dans l'équipe d'administration ?

ben oui, mais il tient à sa règle : "une table = une entité, pas d'héritage entre les entités" (enfin, la conclusion de son doc, quoi)...
 
Mais bon, ranafout', moi, je vais faire avec des sous-classes.

Ils n'étaient intéressés que par l'ensemble des deux prêts ou rien du tout ?
le montant du prêt pour les travaux représentait bcp ?
 
Sinon, c'est un peu normal qu'ils ne t'aient pas proposer de racheter ton prêt immo + prêt pour les travaux,
la loi interdit de le faire (même si certains organismes ne se gênent pas et passent outre)

Je me suis juré d'attendre Novembre pour craquer

Client facing ou pas ?

C'est tellement misogyne que je ne vois pas comment topper ça

KEW KEW
 
Bon j'ai Harko qui se la joue carlos danger et m'envoie des photos de sa bite en dm sur Twitter

Oui enfin dtrace...