[lmi] is DBDictionary's sigleton nature relied on anywhere?

[Václav Slavík]

Hi,

the subject says it — does any code anywhere rely on DBDictionary being a 
singleton?

I don’t quite follow all of that code yet, but from what I understood, it’s not 
relied on in most places (and it’s an obstacle in one) and the code using 
DBDictionary follows the same pattern: it calls instance(), immediately 
followed by some form of Init() to load data into it.

The only place where this pattern isn’t followed is in 
product_database::entity_from_key(), where DBDictionary is only initialized as 
part of product_database construction and then later repeatedly queried in 
entity_from_key().

And this is the part that confuses me: as far as I understand it (possibly 
wrongly), product_database — which is not a singleton, unlike DBDictionary — 
behaves as an obfuscated singleton: if you create 2+ instances of it, Query() 
calls on _any_ instance will return data from the most recently created one 
(worse, even after it’s destroyed).

This would be OK if only one instance of product_database could exist at a 
time, but that’s not the case, I can see multiple coexisting instances if I add 
asserts to check for them. Although they do access the same database in my 
testing, I’m unsure if that’s always the case.

Is this behavior intentional? Am I misunderstanding something? I _think_ it’s a 
defect (one that my caching changes would fix naturally), but I’m not 
sufficiently familiar with these parts of the code to be sure...

Thanks,
Vaclav