Merci Jean-François, effectivement c’est plus simple en Français :) Sais-tu où je pourrai trouver un exemple de ce fonctionnement du design pattern Role en WO?
Pouvons-nous communiquer en direct? Je développe en WO depuis 8 ans et j’ai un problème sur le déploiement. Pourrais-tu m’aider sur ce 2nd point? Rémy. > Le 28 nov. 2017 à 17:22, Jean-François Veillette > <jean_francois_veille...@yahoo.ca> a écrit : > > Bonjour Remy, je me permets de te répondre directement en français, ce sera > probablement plus facile pour nous deux de communiquer dans notre langue > maternelle. > > > Ce que Chuck propose c’est d’utilise le patron des « Roles » au lieu > d’utiliser une structure de classe. > L’idée étant qu’un objet peut changer de rôle, mais ne peut pas changer de > classe. > La logique qui aurait été mise dans la classe sera donc reléguée dans le rôle > (en « sous-traitance »). > > Pour ce qui est des relations polymorphes proprement dites, EOF n’a pas de > problème avec ça. > Cependant pour réduire le nombre de requêtes SQL généré par EOF, on peut > l’aider en encodant la classe (en fait, cela fera référence à sa EOEntity) > dans la clef primaire. > En simplifiant tu aurais quelque chose qui ressemblera à > 0-1024 sont les objets d’entité A > 1025-2048 sont les objets d’entité B > … etc. > En fait, l’idée est de prendre un long (64 bits) et d’en réserver un certain > nombre bits pour y encoder l’entité. De mémoire, j’avais un encodage > d’entité sur 8 bits (256 entités possibles) et une séquence de 56bits (bien > assez long pour mon cas d’utilisation). > J’ai utilisé cette technique avec succès, ça simplifie beaucoup les cas de > relations et les clefs externes. Si je pointe sur une hiérarchie X, avec la > clef je peux donc extraire exactement la partie « entité » et donc à quelle > classe (ou quelle table) je fais référence. > > Bienvenue dans le monde WO ! > -- > Jean-François Veillette > Analyste programmeur / Software Engineer > > >> On Nov 28, 2017, at 4:47 AM, remy <r...@algodata.fr >> <mailto:r...@algodata.fr>> wrote: >> >> Hi Chuck, >> >> How do I this? I think change my method for create my EntitySub but it >> interests me to know this solution. Mostly : "discarding all cached >> knowledge of EO". >> >>> If that is what you need, then look at the Role design pattern instead >> > Where I can find it? >> >> Rémy >> >>> Le 24 nov. 2017 à 19:05, Chuck Hill <ch...@gevityinc.com >>> <mailto:ch...@gevityinc.com>> a écrit : >>> >>> Remy, >>> >>> You *can* get an EO to change its class over time by changing the >>> restricting qualifier, discarding all cached knowledge of EO and doing a >>> fetch. *But* that is really, really not recommended. If that is what you >>> need, then look at the Role design pattern instead. That is probably >>> closer to what you need. >>> >>> If you just need to create instances of different classes based on a string >>> (EntitySub.ENTITY_NAME) then create a factory method that takes the string >>> and returns an instance of a sub-class of EntityAbstract. All of the >>> information needed to do this is in the model and can be referenced at >>> runtime. It is quite simple. The way you are doing it below is just wrong. >>> >>> Chuck >>> >>> From: Webobjects-dev >>> <webobjects-dev-bounces+chill=gevityinc....@lists.apple.com >>> <mailto:webobjects-dev-bounces+chill=gevityinc....@lists.apple.com>> on >>> behalf of remy <r...@algodata.fr <mailto:r...@algodata.fr>> >>> Date: Friday, November 24, 2017 at 2:30 AM >>> To: "webobjects-dev@lists.apple.com >>> <mailto:webobjects-dev@lists.apple.com>" <webobjects-dev@lists.apple.com >>> <mailto:webobjects-dev@lists.apple.com>> >>> Subject: Polymorphic Relationship >>> >>> Hi, >>> >>> I want make an polymorphic entity. >>> >>> I have an Entity Abstract named "EntityAbstract" and a subclass Entity >>> named "EntitySub" where the qualifier is (refEntityName=‘EntitySub'). >>> I have third Entity named "Relation" that has an relationship with >>> "EntitySub". >>> >>> I have a problem when : >>> >>> EOEditingContext editingContext = ERXEC.newEditingContext(); >>> >>> int relationID = Integer.valueOf(relation().primaryKeyInTransaction()); >>> >>> EntityAbstract entityAbstract = >>> ERXEOControlUtilities.createAndInsertObject(editingContext(), >>> EntityAbstract.class); >>> entityAbstract.setRefEntityName(EntitySub.ENTITY_NAME); >>> entityAbstract.setRefEntityID(relationID); >>> >>> editingContext().saveChanges(); >>> >>> ERXEOControlUtilities.refreshObject(relation()); >>> for (EntityAbstract e : relation().entitySubs()) >>> System.err.println(e); // Print <your.app.model.EntityAbstract >>> >>> How to print <Entity pk:"..."> and not <EntityAbstract pk:"..."> ? >>> >>> I don't want use the class "Entity" for >>> ERXEOControlUtilities.createAndInsertObject >>> >>> Do you have an idea? >>> >>> I tested : >>> >>> eo.invalidateAllObjects(); eo.parentObjectStore().invalidateAllObjects(); >>> eo.rootObjectStore().invalidateAllObjects(); >>> It does not work... >>> >>> The project : https://github.com/algodata44/PolymorphicRelationship >>> <https://github.com/algodata44/PolymorphicRelationship> >>> Use DB H2 >>> >>> Thx >> >> _______________________________________________ >> Do not post admin requests to the list. They will be ignored. >> Webobjects-dev mailing list (Webobjects-dev@lists.apple.com >> <mailto:Webobjects-dev@lists.apple.com>) >> Help/Unsubscribe/Update your Subscription: >> https://lists.apple.com/mailman/options/webobjects-dev/jean_francois_veillette%40yahoo.ca >> >> <https://lists.apple.com/mailman/options/webobjects-dev/jean_francois_veillette%40yahoo.ca> >> >> This email sent to jean_francois_veille...@yahoo.ca >> <mailto:jean_francois_veille...@yahoo.ca>
_______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
