collection.includes(memberType) method

Forums for specific tips, techniques and example code
ConvertFromOldNGs
Posts: 5321
Joined: Wed Aug 05, 2009 5:19 pm

collection.includes(memberType) method

Postby ConvertFromOldNGs » Fri Aug 07, 2009 2:28 pm

by Stephen Persson >> Mon, 21 Aug 2000 22:15:49 GMT

Hi,
I'm having problems with the collection.includes() method. I always thought this checked the OBJECT regardless of the key for that object within the collection. However this doesn't appear to be the case.

I have the following piece of code:
if not rProcessor.rAllScheduledJobsByTS.includes(self) then
rProcessor.rAllScheduledJobsByTS.add(self);
endif;

Where rProcessor is a job processor that has a collection of jobs to process, keyed by the timestamp when the job should start.
If a job is already in the queue, but I change the time it should start, based on the above code it should not add it to the queue again - right? Wrong - it does. And continues to do so everytime I change the start time. So I end up with the same instance in the collection numerous times (Using write statement, can see same oid added to collection everytime).
But, if I change the start time back to one of the previous times, it doesn't add it to the collection again.

ie, the includes method seems to be checking the object by looking up its key (timestamp). If same object with same key is present, includes() returns true, but if the same object is present with a different key it returns false.

Stephen Persson
Kinetix Group Ltd

ConvertFromOldNGs
Posts: 5321
Joined: Wed Aug 05, 2009 5:19 pm

Re: collection.includes(memberType) method

Postby ConvertFromOldNGs » Fri Aug 07, 2009 2:28 pm

by Craig Shearer >> Mon, 21 Aug 2000 22:37:46 GMT

Hi Stephen

It would seem that you don't have an inverse from your Job class to the JobProcessor class. If you had this then the collection would automatically be maintained, and you most likely wouldn't have to do the stuff you're trying to do.

What you've written seems to indicate that you've logically corrupted the collection as the collection doesn't have an entry at the right index for the members it now contains... ie looking up the collection with the member's key values doesn't find the object, as you've experienced.

So, what you have is a manually maintained collection (which in general, is a bad thing in JADE). If you have a manually maintained collection (for whatever reason), then it's your responsibility to do the key maintenance - ie, before you change the timestamp on your Job object, you must remove the object from the collection, then change the timestamp, then re-add the Job to the collection.

If you use an inverse, you can avoid all of the above. For example, Job would have a myJobProcessor reference, which, when queued to a JobProcessor would be set. If the Job wasn't queued, then the reference would be null.

HTH

Craig :-)

ConvertFromOldNGs
Posts: 5321
Joined: Wed Aug 05, 2009 5:19 pm

Re: collection.includes(memberType) method

Postby ConvertFromOldNGs » Fri Aug 07, 2009 2:28 pm

by Krull >> Mon, 21 Aug 2000 23:49:01 GMT

Good response Craig!

The 'manual dictionary' issue was also discussed in the article "On Key Maintenance in Manual Dictionaries and Inverse References:" in the May 2000 issue of Jade World: http://news.jadeworld.com/developers/ja ... 0001_6.htm

One other point to bear in mind is that although the includes method is defined at the Collection level, it has a different implementation and search algorithm for each collection type.

Sets and Dictionary's both employ a BTree structure, where entries are accessed via their key values. A Set uses an oid as both the key and the value in the BTree, so Set::includes can employ an efficient binary search using just the object parameter itself. The entries in a dictionary are ordered by their user defined keys and so random access requires key values to perform an efficient search; the MemberKeyDictionary::includes method performs a binary search using the values of the 'key properties' obtained from the object parameter. An array is not organised by any known attribute of its members therefore the Array::includes method must perform a linear search of the array to either locate the entry or determine that it is not present in the array.

Note: the ExternalKeyDictionary class does not implement the includes operation, since be definition an 'external key dictionary' requires keys to be specified for search operations - the includesKey method should be used instead.


Return to “Tips and Techniques”

Who is online

Users browsing this forum: No registered users and 30 guests