We may try to be more clever. Provide an optional argument reRead: if set to true locking will be done by contract id only, if set to false the locking criteria will include the object version.
Should we be more clever? In (programmer's) real life such a specification may prove too restrictive because it prevents incremental updates.
Rework the logic described above: start with the requirements for rating and billing. It is not making sense that billing has to read all 10-20 million Cdr (wholesale contract), on the other hand there's call accounting and bundled rating at billing time.
Redesign is needed once we write subscription charges back to the database:
Most likely we'll have to provide an EditStatus in SubsCharge and an appropriate update function in BsPage.
If a concrete class stores the CDR in a database table, then it will buffer the CDR in push(). However if the buffer gets too big, there might a need to flush the buffer's content, i.e., to write the CDR to the database.
For such a behavior we'd need an OSB_DB::Session as parameter for push() or some kind of callback function.
An IMSI is always coupled to another resource, e.g., MEID or SIM card.
The question is if an IMSI is "just" an attribute of this other resource or if it can live stand-alone: The latter is expected and in this case we must decide who stores the relationship.
Provide functions init<X>(const Session&) to initialize the list pointers and read their content from the database; throw in the list access functions if a pointer is 0.
When and how do we check, if the item can be deleted? Exemple: Resource assignments must not be removed until the rating reproduction time has passed. Is this issue general, specific to some item types or both?
The current processing logic breaks in the moment we really have >1 entity linked to a request.
Then we first need to set the preferred status of all entities and the apply the request for the cascading root only.
Currently (May-06) is not clear if the class should be derived from a base class Equipment and, if so, what would be the interface of such a base class.
Allow parametrisation of OSB_LIB::ModAccess and OSB_LIB::GrpAccess:
Provide an inner class Param which can have to following types (boolean should not be needed):
none: access nodes
long: min, max value
double: min, max value
string: usage?
long list: list of object id's
string list: usage? Note that the parameter type is the same for both classes, however the class Param itself will be completely different.
The current implementation fills missing bytes with 0.
That's why ASCII strings can be decoded. To support any data we'd have to store the data size in the first 4 bytes during encoding and read back during decryption.