>Some vendors have optimizations for this type of thing. For instance,
>Weblogic has the concept of field groups. Here's the documentation on them
>from the XDoclet docs on the @weblogic:field-group tag:
>

Thanks for the info.  Not sure how to get the doc.  Is there an URL for it?
What is XDoclet?


>
>
>A field-group represents a subset of the cmp and cmr-fields of a bean.
>Related fields in a bean can be put into groups which are faulted
>into memory together as a unit. A group can be associated with a
>query or relationship, so that when a bean is loaded as the
>result of executing a query or following a relationship, only the
>fields mentioned in the group are loaded.
>
>A special group named 'default' is used for queriess and relationships
>that have no group specified. By default, the 'default' group contains
>all of a bean's cmp-fields and any cmr-fields that add a foreign key to the
>persistent state of the bean.
>
>A field may belong to multiple groups. In this case, the getXXX() method
>for the field will fault in the first group (lexically speaking) that
>contains the field.
>

A few questions about this field-group idea...

Is each field-group a separate object from the base object?  If I have Order
base object and want a field-group that only projects 5 columns, do I end up
during running of app one Order instance and one OrderFieldGroup instance?

If I do (have a separate object for field-group), is the field-group an
entity bean as well?

How are updates managed?  If I change a field in Order through one
field-group, would other field-groups see them?  Or, am I required to write
the change to database and reload?

>
>
>In this way you can have partially initialized objects that only pull in
>the pieces it thinks it needs... While this is a vendor-specific
>optimization, it is mapped into the weblogic deployment descriptor, so it
>does not make your code any less portable (although you won't have these
>optimizations on another product, unless they have something similar).
>

No offense, but to me "vendor-specific optimization" is euphemism for
non-portability.  Another vendor's implementation simply won't match
weblogic's.  Unless it gets in the spec (and all vendors agree to
implement), it's not standard.  Therein lies my concern about the emerging
standard.


Thank you.


Atong


>HTH,
>
>Jason Carreira
>
>===========================================================================
>To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
>of the message "signoff EJB-INTEREST".  For general help, send email to
>[EMAIL PROTECTED] and include in the body of the message "help".
>


_________________________________________________________________
Chat with friends online, try MSN Messenger: http://messenger.msn.com

===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST".  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".

Reply via email to