[ http://jira.andromda.org/browse/EJB-35?page=all ]
Sverker Abrahamsson updated EJB-35:
-----------------------------------
Attachment: andromda-plugins.patch
> Finder methods, named queries and relations
> -------------------------------------------
>
> Key: EJB-35
> URL: http://jira.andromda.org/browse/EJB-35
> Project: EJB Cartridge
> Type: Improvement
> Reporter: Sverker Abrahamsson
> Assignee: Vance Karimi
> Priority: Trivial
> Attachments: andromda-all.patch, andromda-plugins.patch
>
> Most of my queries involve related classes. For example, I have an entity
> Subscription with a 0-n relation to entity User and a n-1 relation to entity
> Channel. I want a finder method which returns all channels a given user is
> subscribed to, without having to load neither the User nor the Subscription
> entities (this is a quite trivial example, there are more complicated cases
> where the difference acctually affects performance).
> So I create a finder method in Channel called findSubscribedChannels(String
> msisdn) where msisdn is primary key of User entity. This finder method should
> return a collection of channels the given user is subscribed to.
> The generated query is of course not correct but I thought it sholdn't be a
> problem as I could override it in the DaoImpl class, but the problem is that
> since it's created as a named query then JBoss verifies it when the
> application is deployed and fails since Channel doesn't have any field named
> msisdn.
> As the doc indicated that there are no possibility to override the generated
> query except by creating a OCL query, I started to ponder how to solve this
> issue (I later found that @andromda.ejb.query tagged value does work
> countrary to what the doc says). I thought that if I instead specified the
> signature as findSubscribedChannels(String subscriptions.user.msisdn) (where
> subscriptions and user are the respective relation names) then the query
> generator could detect that this finder argument refers to a field in a
> related entity. It acctually worked out very conveniently. For this finder
> method a query like this is generated:
> select channel from Channel as channel inner join channel.subscriptions
> as subscription where
> subscription.user.msisdn = :subscriptionsUserMsisdn
> Hence as long as just a simple query is neccesary then nothing else than
> specifying the finder parameters results in a working query even when the
> query involves several related enties.
> To make it work I had to do a patch also for the main andromda project as the
> signature of a finder method is created there but unless a operation
> parameter name is allowed to have dot's in some context (I can't think of
> any) it shouldn't affect anything negatively.
> Now that I found out that I can override the named query with
> @andromda.ejb.query maybe this patch isn't that neccesary but I still find it
> convenient as it makes it visible directly in the model which attributes are
> involved in the search.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.andromda.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
