[odb-users] Re: read-only fields

[Вячеслав Спиридонов]

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
mask.

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() ).

Thanx,
Viacheslav

----------------------------------------------------------------------
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
>