klayout
klayout copied to clipboard
rdb python/ruby module: modifing items not possible as they are const
Hi Matthias,
I am wondering whether there is a strong reason for the rdb
module and RecordDatabase
in particular to return const
objects instead of modifiable items. I am in particular interested in setting tags (and potentially images) on items. Currently if I understand the inteface correctly, I would have to rebuild the whole rdb from scratch after reading it just to set tags. Is there already an easier way? (I know I could theoretically go through xml, but that seems unnecessarily complicated)
Would it be possible to create iterators which return the modifiable items? (same for categories etc would be nice, but I get it, maybe the architecture doesn't allow this)
Best, Sebastian
Hi Sebastian,
right now, the RDB API is made for reading and creating databases. Manipulation was not the scope of the API. Beside mutable RdbItem references you would also need methods to remove items and also other objects need manipulation support (cells, tags, categories).
Matthias
Hmm, I see.
My goal was to make a dumb script to take two reports, and take over flags on item1 from report1 to item2 report2 if calculated hashes of match (strings and all shapes should have unique enough hashes to allow this). This would easily allow me to takeover flags from old drc reports to new ones and also easily find new rule violations.
I guess I can just duplicate rdb2 from scratch and apply flags there though.
You can leave this ticket open as a reminder. I think that is a fair request, it's just not there and will be a little effort.
@klayoutmatthias I have found something interesting in the rdb API ^^:
The each_category()
of the database returns const categories, categories retrieved by id also return const categories. But parent()
on a category returns a non-const category and same for each_sub_category()
. Therefore it's impossible to rebuild category tries by purely reading the rdb, unless they are only one level deep. Unless I am missing something, of course.
For now I can get around it by splitting the path on '.', but I consider that as shakey at best, because I noticed categories are allowed to contain '.' in their name
Hi Sebastian,
sorry for the delay - there are too many other topics :(
I created a patch that fixes the systematic issues with "parent" and "each_sub_category". I have also created non-const versions of all the access and iterator methods (I hope I did no miss something). See the "issue-1632" branch (linked to this ticket) for details.
Yet, the options are somewhat limited as the database is not truly manipulation enabled. You can change the values of items or their tags. You can change the scalar non-key attributes such as category descriptions. But you cannot remove or rename cells for example. It's also likely that certain scenarios such as adding cells while iterating them will crash the application. So the API is not really foolproof.
Matthias
Hi Matthias,
No problem at all. I found a way to make it work. I was able to write a regex which can split category paths. So no rush about implementing it.
I think expecting no systematic change during iteration is a reasonable expectation. Recursive iterators also don't like changes during iteration.
Thank you very much for the quick fix. I thought this was something that would be nice for 0.29. That's mainly why I brought it up ;)