Re: [lmi] product_editor .db4 files and TDBDictionary public interface (/singleton)

[Greg Chicares]

On 2006-2-15 11:42 UTC, Evgeniy Tarassov wrote:
>
> To implement .db4 files editing in new product_editor i've used
> TDBDictionary class (from ihs_dbdict.hpp) but i was forced to use some
> nasty workaround. The class itself is supposed to be singleton and has
> no public method to dump the data from memory to a file. I've managed
> to workaround those issues:
> 1. to have more than one .db4 file open at the same time (class is a 
> signleton)

In the legacy implementation of the product editor, astonishing
things happen if you have two '.db4' files open at the same time.

Normally, lmi users work with a single product at a time, so
they may use the same '.db4' file for hours or even days. For
that normal usage, caching makes the system much more responsive;
I haven't measured that recently, but it made a big difference
years ago.

A singleton whose data are overwritten when the product changes
is a very unsophisticated cache implementation, but it was quite
easy to do. It does have this distressing side effect for the
product editor, though--and stands in the way of threading, which
we might want some day.

> To read the data from a file i create anew dict_map (container used to
> store elements from the dictionary), then i swap it with the
> dictionary container, then read the data from file and swap again.
> dict_map myMap;
> TDBDictionary::instance().GetDictionary().swap( myMap );
> TDBDictionary::instance().Init( myFilename ); // reading data
> TDBDictionary::instance().swap( myMap );
> I need also to clean the cached filename to make it work correctly.

For now, it makes sense to do whatever works.

The ancient 'TDBDictionary' needs to be rewritten someday, but
we can't do that until the new product editor enables us to stop
using the legacy editor.

> 2. To access private methods (WriteDB) to write the data back to the file
> There is a friend declaration with a class DatabaseDocument which does
> not exist. To acces those internal functions of dictionary i've added
> class with that name, derived from it, etc.
> 
> Do you think that this approach is appropriate?

Yes.

> While 1 could be considered correct from a point of view
> (TDBDictionary is treated like a factory-gateway class)

The way you're using (1) to solve the problem is OK, but the
underlying architecture isn't right: if 'TDBDictionary' should
be a Factory, then implementing it as a Singleton (years ago)
isn't the right way today. We'll keep that in mind when we
eventually rewrite that class.

> 2 is more
> lika a hack. Do you think that i should modify the interface of the
> TDBDictionary to expose some needed functionality? (like mkaing
> WriteDB to be public and adding a couple of function to purge cached
> file name, etc)?

Only if necessary. I'd hesitate to change those existing classes:
they haven't really been touched for years, and they need to be
completely rewritten in the future anyway. If it would help to
add a few more friend declarations, then that's OK because it
can't conceivably cause problems elsewhere.

In this case, I guess the 'Design Patterns' people would recommend
an Adaptor, which is what I think you're already doing. I'd say
that's the best way.