Getting Rid of Multiple Record Objects of the Same Record

Daniel Manocchio

Hi guys,

When a record is loaded twice in STK, e.g. via get_record_by_id(), this results in two record objects of the same record, but with different Python IDs and hashes. Hence, it's not possible to avoid such duplicates entering record lists via "if rec not in list()" or to clean an already existing record list via list(set()).

In the past, I my workaround was creating a dictionary, containing the record names as key and the record objects as value. But this isn't really an elegant workaround.

So I'd like to know whether there's a best practice to keep record lists free of such multiple record objects?

Thanks in advance & bests,
Daniel

Andy_Grigg

Hi Daniel,

First off, excellent question! Ultimately, I think the approach you've described is what I'd recommend, and how I've solved this problem in the past. I wouldn't use the record names though, since record names are not necessarily unique in a database.

A dictionary based on something like the record GUID or record history GUID would be best, and if you know you're storing records from different databases, a tuple of (db_key, record_guid) would be the most robust approach, since record GUIDs and record history GUIDs are not guaranteed to be unique across databases.

If all you're interested in is the recommended approach to this problem, then you don't need to read any further. If you want some more background as to why Scripting Toolkit doesn't do something more clever, then read on.

---

In order to make the functionality you describe we'd have to define a meaningful hash for a record object. This is more difficult than it sounds though, because there's so much state <?WORD FLAGGED?> in a Record object, such as:

• The state of the attributes dictionary, including which attributes have been exported, if they've been modified, if they've been staged for import, their units, etc.
• The state of the links dictionary, including whether all links have been exported and/or modified
• The current state of the subsets for the record

We'd also have to understand what the user intended if they tried to export a new record object where one already exists. Would that mean the user wanted to replace that object, or merge them? Or raise an exception because there's already a record exported? With this amount of complexity, it would be extremely easy to introduce bugs here, or at least unexpected behavior in certain circumstances.

Given that the alternative is to use a dictionary with a well-chosen key (for your particular definition of uniqueness), it feels like it's best to leave this to the user and their particular implementation, instead of trying to design a solution that will work for all users in all situations.