OK I understand now - identity will only solve a little bit of the problem.
Yeah its a good idea to implement them anyway (read Joshua Blochs Effective Java book for reasons - I think those chapters are online and free..) If the rules were to work on string objects, then you get equals and hashcode for free, but like you say it is work to "map" your objects to the objects for the rule (which is work) so perhaps implementing your own hashCode and equals is a good thing. Lots of rule engines work on deftemplate like structures, which is kind of the same idea - you have to map your domain objects to the rules model. You hit the nail on the head when you said it is like OR mapping - for more complex structures it is quite difficult. Part of the popularity of Drools is the fact that you can just shove in your POJOs and work off them in the rules (but it makes it hard to implement !). The declarative approach could work - having a rule with higher salience to remove the dupes - and it makes it explicit, but I am not sure what that means performance wise. Basically you have a "disallow_dupes" rule which does the check, and retracts the object if it is a duplicate - my gut feel says the set approach is more efficient in drools 2. Mark might be able to comment on the Drools 3 ways of addressing this, as there will be more options. It sounds (from what Bob alluded to) that there could be some flavours of drools tilted towards reasoning, which this sort of behaviour is enabled by default. Michael. On 1/24/06, Peter Van Weert <[EMAIL PROTECTED]> wrote: > > Andreas Andreakis wrote: > > > I agree, that it is not a beautiful solution. > > > > But the problem is, that you can´t tell if two Objects are equal if > > you dont define equals() , hashcode() on your own. How will your > > dublication-preventing Rule look like ? > > I would simply implement the equal and hashcode methods :-) > It is general good practice to do so and it is quite easy: an equals > method is almost trivial, and for the hashcode you can use e.g. > http://www.javapractices.com/Topic28.cjp if you want... > > > Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm > > >
