-
1. Re: To merge or not to merge?
starksm64 Oct 10, 2006 2:50 PM (in response to adrian.brock)This is what I was referring to previously about a unified api for traversing/merging the various scopes of data. This also intersects with the discussion on how overlapping annotation collections are merged. There is a tradeoff between having a framework that generally can build up something like a JndiBinding vs having to write the merge logic in terms of delgating accessors.
Given n scopes of data of types T1...Tn, and a unfied type T (which usually would be amongst T1...Tn I would expect), the ideal thing would be to have the framework piece together the type instances so that T.x was a merge ot the T1...Tn sources of the property x. How to write this without significat restrictions on how the types relates seems non-trivial at this point. -
2. Re: To merge or not to merge?
adrian.brock Oct 13, 2006 9:14 AM (in response to adrian.brock)But I think we are talking about different things, at least from
my understanding of your original post.
There is a need to merge/hide/override at runtime and this
depends upon the type of metadata (it also includes having the
ability to query where the data came from).
The full normalized view should be maintained elsewhere.
When I talk about merging I'm talking about giving the runtime view,
e.g. getting all the resource-refs for a bean (from all levels). -
3. Re: To merge or not to merge?
starksm64 Oct 13, 2006 1:01 PM (in response to adrian.brock)"adrian@jboss.org" wrote:
But I think we are talking about different things, at least from
my understanding of your original post.
There is a need to merge/hide/override at runtime and this
depends upon the type of metadata (it also includes having the
ability to query where the data came from).
Argreed, but runtime usage vs asking where runtime T.x actually came from seem like two different uses of the composite metadata for the type T. One way to get the runtime view would be to collapse the levels into an instance T. Another would be a T facade over delegating accessors/iterators that do the right thing for each property x of T."adrian@jboss.org" wrote:
The full normalized view should be maintained elsewhere.
I'm not following what you mean by normalized view?"adrian@jboss.org" wrote:
When I talk about merging I'm talking about giving the runtime view,
e.g. getting all the resource-refs for a bean (from all levels).
Yes, that is what I would consider as merging as well. -
4. Re: To merge or not to merge?
adrian.brock Oct 27, 2006 9:12 AM (in response to adrian.brock)"scott.stark@jboss.org" wrote:
"adrian@jboss.org" wrote:
The full normalized view should be maintained elsewhere.
I'm not following what you mean by normalized view?
The normalized view is all the information coupled with where it is defined
not the merged/denormalized view.
i.e. at runtime you say
"What are the resources for this ejb?"
"What is the transaction timeout for this ejb method?"
which comes from the denormalized view, i.e. you get all the resources
that are relevant for the ejb, or the transaction timeout for that context
(regardless of where it is defined).
Elsewhere you use the normalized view, so the responses will be
different:
"What are the resources for this ejb?"
Will only include those actually defined on the ejb not those
defined at e.g. deployment level for which you would need to ask
the normalized view:
"What are the resources for this deployment?"
Similarly for the transaction timeout. The denormalized should
always give you an answer (even if it is just the timeout defined at
server/domain level).
The normalized view will only give you an answer if something
is defined against that ejb method.
In the normalized view you can ask:
"Is there a transaction timeout for this ejb method?"
"Is there a transaction timeout for this ejb?"
"Is there a transaction timeout for this deployment?"
"Is there a transaction timeout for this server?"
etc.