[odb-users] Re: read-only fields

Вячеслав Спиридонов art at it-gen.net
Fri Sep 2 06:13:14 EDT 2011

Dear, Boris and odb-users

The proposed variant will work exactly as we need. And about an
implementation of the RO, I think that is almost perfect might be
run-time decision - mask of properties members of object. Then do not
have to divide an object into two parts, just manipulate the value of

A typical example. For the first time create the object. You must
initialize all the fields Default values ​​and display it in the
database (persist()). This means that all object fields should be
writable, after this a part of fields has become a RO. Any further
update () is not allowed to overwrite these fields in the database.
Because we want to reserve ( regardless of whether the currently
cached object in memory and perhaps in the future will be thrown in
the database update() ) the exclusive right to manually change some
fields directly in the database. As well as an option at all can make
individual masks for each event ( persist(), update(), load() ).


1 сентября 2011 г. 21:17 пользователь Boris Kolpackov
<boris at codesynthesis.com> написал:
> Hi Viacheslav,
> Вячеслав Спиридонов <art at it-gen.net> writes:
>> Please can you tell me will be ODB to support read-only fields?
> We have actually thought about this but it turns out not so easy to
> implement. Ideally, a read-only member would only be ignored in the
> update() call. In particular, it should still be used when we make
> the object persistent with the persist() call. This would be similar
> to how const members are treated in C++ constructors (i.e., in a
> constructor a const member is not considered const).
> The difficulty is with ignoring the member for update() but still
> passing it for persist(). Right now the update() and persist()
> functionality share what we call an "object image". An image is
> basically the object state expressed in database API types. If
> an object has read-only members, then we would need two separate
> images.
> We could probably implement an interim solution where a read-only
> member is ignored for both update() and persist(). Would that work
> for you?
> Boris

More information about the odb-users mailing list