Am I correct that here is no way to store the "handle" of an object, i.e, int(ObjRef) and then to efficiently get back to the object, e.g. to provide the return value for a Get which was intended to return the object. Presumably, one could walk the session object tree looking for the same handle and then return the object, but that seems unlikely to be efficient.
None that I've seen.
Unless you store all created objects in a static temp-table and return
a GUID (which is a unique key on the table)
Julian
On 6 June 2010 20:16, Thomas Mercer-Hursh
Well, int(ObjRef) would provide an adequate key on the table.
Hmmm, maybe I'll have to benchmark that. It seems expensive, especially since every NEW would have to register the object and it could be a potentially large table.
In fact, I suppose one would almost have to define an Entity base class that all entity classes inherited from and include registriing and deregistering in the constructor and destructor.
tamhas wrote:
Well, int(ObjRef) would provide an adequate key on the table.
Hmmm, maybe I'll have to benchmark that. It seems expensive, especially since every NEW would have to register the object and it could be a potentially large table.
In fact, I suppose one would almost have to define an Entity base class that all entity classes inherited from and include registriing and deregistering in the constructor and destructor.
You can use the object reference as-is as an index on a temp-table. There's no need to convert to an integer.
There was some discussion of the performance issues in this thread: http://communities.progress.com/pcom/thread/24815?tstart=0 What's your use-case for storing the integer value (especially given the last comment on that thread:)?
If you must use an integer, I did some tests for the above thread, and came up with a time of 325ms to traverse the session object tree, with 100k objects (http://communities.progress.com/pcom/message/83769#83769). Whether that's acceptable or reasonable is up to you.
-- peter
One of my use cases is related to some explorations I am doing on collections and trying to avoid the weight of a TT. WT is one option, but it doesn't support objects of type PLO, but it could store an integer.
tamhas wrote:
One of my use cases is related to some explorations I am doing on collections and trying to avoid the weight of a TT. WT is one option, but it doesn't support objects of type PLO, but it could store an integer.
One of the things you'll have to keep in mind with this approach is that the weak reference doesn't prevent the garbage collector from cleaning up the referenced object. Unless the application disables the garbage collector (which is an active decision, since the default is an enabled GC), you're going to lose some/all of the collected objects. How important an issue this is depends on how much control you have over the library's use.
-- peter
Understood.