[odb-users] Re: read-only fields

[Boris Kolpackov]

Hi Viacheslav,

Вячеслав Спиридонов <art at it-gen.net> writes:

> The proposed variant will work exactly as we need.

Ok, I will try to implement it before the next release.


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

Yes, that sounds like a good idea in general, however, it has one
major drawback -- efficiency. Right now ODB prepares the text of
statements (for persist, update, load, etc) at compile-time because
it knows how many data members an object has, their types, etc. At
runtime it used database-prepared statement and caches/reuses them
(actually, each object has a set of cached prepared statement for
each database connection). The functions that convert between objects
and their images as well as bind parameters/results are also very
simple because the ODB compiler knows a lot of things about the
object at compile time. In other words, ODB is designed to be very
efficient. And, not surprisingly, some users reported several orders
of magnitude performance advantage compared to more "dynamic" ORMs
such as Hibernate for Java.

Now, if we have to decide at runtime which members must be sent to
the database, a lot of these optimizations become impossible: We
cannot prepare text for statements because we don't know which
values will be sent. So we have to do it at runtime. Worse yet,
we cannot cache/reuse prepared statements because there could
be a large number of them, each for a certain combination of
data members. The various functions I mentioned above will also
become more complex because now they need to check whether each
member is actually being sent.

Having said that, the mask idea is not bad, and we have already
thought about something like this in the context of change
tracking/detection with the goal of producing minimal updates.
Right now, ODB will send the complete object even if only one
member has been changed. This is obviously not ideal but the
alternatives have major drawbacks as well, as I have described
above. One middle-ground solution to this might be the ability
to "partition" data members in an object into multiple "sections"
that can be loaded/updated independently.

Boris