[Hibernate-issues] [Hibernate-JIRA] Closed: (HB-270) Ability to choose accessors/ fields/both for population

[<leg...@at...>]

Message:

   The following issue has been closed.

   Resolver: Gavin King
       Date: Sat, 13 Sep 2003 9:35 AM

I implemented something very similar to this, (after looking over this patch). The main differences are
(1) do things at the property level with a new access attribute
(2) designed a pluggable PropertyAccessor interface

Thanks!
---------------------------------------------------------------------
View the issue:

  http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-270


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-270
    Summary: Ability to choose accessors/ fields/both for population
       Type: Patch

     Status: Closed
   Priority: Major
 Resolution: FIXED

    Project: Hibernate2
 Components: 
             core
   Fix Fors:
             2.1 final
   Versions:
             2.0.2

   Assignee: 
   Reporter: Vladimir Dozen

    Created: Sat, 16 Aug 2003 2:46 PM
    Updated: Sat, 13 Sep 2003 9:35 AM
Environment: Any

Description:
Hibernate uses setters/getters to access properties of objects.
This may lead to unconvinience, unstability or performance hit in
various situations. The patch provides ability for programmer to
choose what method will use Hibernate: accessors (default), fields,
accessors-then-fields, fields-then-accessors. Developer may explicitely
mark specific classes as accessible via fields or methods.

Example: unconvinience:

We have a lot of POD structures (i.e. structures which has all
fields as public final) and forcing to provide getters/setters
is just doesn't give any profit and simply unconvinient (BTW: and impossible without removing final).

Example: unstablity:

Often setter contain some code to check validity of the passed
arguments. That's fine when the system that uses Hibernate is the
only way to DB. But, when integrating with legacy systems, we cannot
be sure incorrect data cannot get into DB. When Hibernate attempt then
load such object from the DB using that checking setter, it will get
exception and will fail. The same applies also for multi-row selects and even to loading objects of another types that has (non-lazy) references to broken object. System becomes mostly unusable.

Example: performance:

Validity checks in setters can sometimes take significant amount of
time. For example, time to check if the word exists in some dictionary
grows as log2(n), and can be large enough. Multi-row selects makes the
things even worse.

Workarounds like making alternative set of accessors are ugly, and
make the code messed.

The patch adds hibernate.conf option hibernate.access.order that can
have following values: "accessors-only" (default), "fields-only",
"fields-then-accessors" and "accessors-then-fields". According to
the option Hibernate will scan the object for properties or setters/getter. Plus, using special marker interfaces ReflectHelper.AccessibleViaMethodsOnly, ... programmer can mark specific class as to be accessible using specific method.




---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.

If you think it was sent incorrectly contact one of the administrators:
   http://opensource.atlassian.com/projects/hibernate/secure/Administrators.jspa

If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira