[ http://jira.jboss.com/jira/browse/JBAS-56?page=history ]
SourceForge User closed JBAS-56:
--------------------------------
Resolution: Done
> Nested Properties in CMP
> ------------------------
>
> Key: JBAS-56
> URL: http://jira.jboss.com/jira/browse/JBAS-56
> Project: JBoss Application Server
> Type: Feature Request
> Reporter: SourceForge User
> Assignee: Scott M Stark
>
>
> SourceForge Submitter: vharcq .
> I would like to add a small (well a big for me)
> feature to Entity EJB 1.1 in
> CMP mode.
> Dirk Zimmermann has already make some changes for that
> and I would like to
> extend them.
> I also would like your opinion on that.
> We could call it "Nested Properties in CMP".
> Current State
> -------------
> When we define cmp-field, they are saved into a
> corresponding field in the
> database. If the original java type is primitive, it
> is transform to sql
> type. If the original java type is not, it is
> serialized and saved as
> object.
> When you read the database not from EJB, you need to
> deserialize the object
> to get its value. Not a problem with JDBC but when
> you want to access the
> database in other ways, you got stuck.
> Dirk Improvement
> ----------------
> The goal of Dirk (AFAIK) was in the case of one bean B
> reference Primary Key
> of bean A as a field. Dirk wanted to also stored
> the "inside" fields of the
> A Primary Key as primitive type when they are. In
> fact they almost always
> are. One Primary Key class is often one (or multiple)
> primitive type like
> an "int" for example.
> So he added the possibility to add in jaws.xml
> <cmp-field>
> <field-name>apk.id</field-name>
> <column-name>apkid</column-name>
> </cmp-field>
> In this case both apk is serialized AND the id inside
> apk is saved as
> integer in a new field.
> Then very easy now to sql JOIN two tables.
> Very nice indeed :)
> Wanted Improvement
> ------------------
> Extend that to any "non-primitive" cmp-field.
> If I have an Address as a cmp-field, I may want
> to "explode" it in multple
> primitive fields street, city, zip, country and save
> these fields instead of
> serializing Address.
> The workaround to do that today is to have all Address
> attributes as EJB
> cmp-fields and implement a Address getAddress() method
> inside the bean,
> declare it in the remote interface, ... very borring
> in fact, not OO, and I
> am very lazzy too.
> If you change Address, you have to review all EJB that
> use Address, beurk.
> If you want a finder method on Zip code of Address,
> you can not serialize
> Address or if you do, you have to findAll() then verify
> getAddress().getZip(), beurk.
> I don't think this is against the 1.1 spec as the
> 9.4.1 chapter is very
> "vague".
> I also don't think it go against 2.0 spec as this is
> really not in conflict
> with Dependant Objects which are more complex that my
> case. (in D.O. the
> address could be shared by two entity beans for
> example, or stored in
> another table).
> The biggest warrning to make I think is regarding
> chapter 9.2 of the spec
> 2.0 which says :
> " When designing an entity bean with container
> managed persistence, the
> Bean Provider must be mindful
> of the distinction between the client view of
> the entity bean and the
> entity beans view of its persistent
> state. In particular, there need be no direct
> relationship between the two.
> While the EJB component
> model provides a separation between the client
> view of a bean (as presented
> by its home and remote
> interfaces) and the entity bean instance
> (which provides the implementation
> of the client view), the EJB
> architecture for container managed persistence
> adds to this a separation
> between the entity bean
> instance (as defined by the bean provider) and
> its persistent state."
> I really think this improvement does not go against
> that because I am
> focusing on very basic views : Address, Quantity, ...
> The kind of fields that you do not want to transform
> each time in the EJB to
> provide a client with its own view.
> A Quantity is a Quantity ! for both server side
> componants and client side
> components. For the Address example, it depends of
> what you want to do with
> the Address, right. But if you know what you are
> doing . . .
> How I plan to do it
> -------------------
> I would like to do that without changing the default
> behavior, so my ejb-jar
> remains unchanged and define Address as the cmp-
> field. (This is what I want
> to "publish" in my get/set in the remote interface).
> The changes would
> appear in jaws.xml.
> 1. If I do not specify anything, Address is still
> serialized as before.
> 2. If I specify Address, Address is still serialized
> as before.
> 3. If I add Address.zip like this
> <cmp-field>
> <field-name>address.zip</field-name>
> <column-name>addresszip</column-name>
> </cmp-field>
> I will have both Address Serialized and Address.zip
> saved in 2 columns.
> Address remains the important data (If I change
> Address my sql, my EJB show
> the change - If I change addresszip by SQL then my EJB
> do not see anything).
> This would be helpful for "Catalog" pattern sort of
> things in Read Only SQL
> only.
> 4. If I tell Jaws that Address is "exploded", then
> Address will be
> reconstruct from its different fields.
> Address would be exploded if I do not specify any
> <column-name> for it.
> <cmp-field>
> <field-name>address</field-name>
> <column-name></column-name>
> </cmp-field>
> <cmp-field>
> <field-name>address.street</field-name>
> <column-name>addr-treet</column-name>
> </cmp-field>
> <cmp-field>
> <field-name>address.zip</field-name>
> <column-name>zip</column-name>
> </cmp-field>
> If I forgot (as in this example) to map some fields,
> they will be mapped by
> default to
> address_fieldname
> I tell Jaws to explode a cmp-field by not specifying a
> column-name for it.
> IMHO that's a simple trick that will permit to
> transform a lot of code
> working now with a minimum amount of change. (I am an
> addict to ejbdoclet
> and I ant to keep this change as transparent as
> possible).
> 5. This has to work recursively and automatically for
> nested properties.
> If Address and a street property which is himself 3
> String line1, line2,
> line3,
> Then I only have to specify
> <cmp-field>
> <field-name>address</field-name>
> <column-name></column-name>
> </cmp-field>
> And I will get in my database
> address_street_line1
> address_street_line2
> address_street_line3
> address_zip
> address_city
> address_country
> So per default I automatically explode the nested
> properties. Not
> automatically for the first field to keep the standard
> behaviour.
> 6. Yes you have to create a jaws.xml to make it work!
> I do not use them and
> try to make jaws work per default most of the time.
> Maybe a flag in
> standardjaws.xml would be an idea.
> <explode-nested-properties>
> true
> </explode-nested-properties>
> This would make (5) work without having to write a
> jaws.xml.
> But maybe it is going too far.
> 7. Finder Methods
> They will work better with this!
> You can now have a findByZip(String zip) method on the
> bean.
> findByAddress() is no more possible but not needed as
> well.
> For the Quantity object, if it has a double value and
> a String unit, you
> could now have a findByUnit()
> [Future] Arrays and Collections
> -------------------------------
> This could be extended for Arrays (and Collections).
> Here I face the problem that Array is not a SQL
> standard (I have seen them
> in Postgres but not in Hypersonic)
> If an cmp-field is an Array and the database allows
> Arrays, it should be
> possible to map these fields to SQL arrays and not
> Serialize them.
> If Address define String[] street, today it is
> serialized, I would like to
> create a VARCHAR[] field in compliant database instead.
> This is for the future as it will require a lot more
> work to verify all
> supported databases and I am not really sure I am
> going too far here. . .
> Please give your opinion.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/
_______________________________________________
JBoss-Development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
