Regarding the post-query,(using for getting the description field
which is in another table such as viewing the name of department when
there is only department_id in the VO of employee) as you now we have
2 common ways to handle that first is to use two EO that there is an
association between them which one of them is updatable and the other
is just for reference and presenting the description field.
the other ways which of course is not very good is using a transient
field and override the get method for it in order to return the
description.
The way that I want to present is totally different from two mentioned
methods, I have not see this method any where in any
blog,forum,official or unofficial document;So I decided to present
this method and I would be appreciated if you, as a professional
developer, scrutinize this method to give me and others the cons and
pros.
In this method, for any description fields we would add a transient
field in the view ( it is not important that the VO is readonly or is
based on the EO)for example we would add the transient field
testDescription in the VO. next, in the query for the view we need to
change the query (if it is based on the EO we have to choose expert in
the sql mode) and add the blew to the select query
(select descritption form example_table where
example_table.id=viewquerytable.id) as testDescription
it is obvious that in this way the description would come along with
the query itself so there is not any extra round-trip to DB for
querying the description and also there is no need to add any extra EO
and Association for getting the description field.
I have add a sample,to see it in action (pls use the application
module tester as I have not add any page.)the sample is using the hr
schema.
I was investigating this approach before and I had one problem - one page
load it works fine, but when user is changing LOV value, description text
wasn't required from database. At that point of time, it wasnt possible to
set AutoSubmit on Attribute level in VO. Probably it will work now, with
AutoSubmit set to true and Dependency enabled.
I dont recommend you to switch VO to Expert mode, there can be problems in
the future between VO Attribute and SQL column mapping. Also if you are
using Java Impl classes for VO's, you can get not synchronized attributes
while in Expert mode. Its better you can define SQL statement directly on
transient attribute in Expression field.
> Regarding the post-query,(using for getting the description field
> which is in another table such as viewing the name of department when
> there is only department_id in the VO of employee) as you now we have
> 2 common ways to handle that first is to use two EO that there is an
> association between them which one of them is updatable and the other
> is just for reference and presenting the description field.
> the other ways which of course is not very good is using a transient
> field and override the get method for it in order to return the
> description.
> The way that I want to present is totally different from two mentioned
> methods, I have not see this method any where in any
> blog,forum,official or unofficial document;So I decided to present
> this method and I would be appreciated if you, as a professional
> developer, scrutinize this method to give me and others the cons and
> pros.
> In this method, for any description fields we would add a transient
> field in the view ( it is not important that the VO is readonly or is
> based on the EO)for example we would add the transient field
> testDescription in the VO. next, in the query for the view we need to
> change the query (if it is based on the EO we have to choose expert in
> the sql mode) and add the blew to the select query
> (select descritption form example_table where
> example_table.id=viewquerytable.id) as testDescription
> it is obvious that in this way the description would come along with
> the query itself so there is not any extra round-trip to DB for
> querying the description and also there is no need to add any extra EO
> and Association for getting the description field.
> I have add a sample,to see it in action (pls use the application
> module tester as I have not add any page.)the sample is using the hr
> schema.
> --
> You received this message because you are subscribed to the ADF Enterprise
> Methodology Group (http://groups.google.com/group/adf-methodology). To
> unsubscribe send email to adf-methodology+unsubscribe@googlegroups.com<adf-methodology%2Bunsubscribe@ googlegroups.com>
Thanks for your reply I was not able to handle the description via
Expression. it seems that is would not accept any sql query
such as
*
select descritption form example_table where example_table.id=
viewquerytable.id*
Thanks,
Amir
On Sat, Oct 31, 2009 at 4:04 PM, Andrejus Baranovskis <
> I was investigating this approach before and I had one problem - one page
> load it works fine, but when user is changing LOV value, description text
> wasn't required from database. At that point of time, it wasnt possible to
> set AutoSubmit on Attribute level in VO. Probably it will work now, with
> AutoSubmit set to true and Dependency enabled.
> I dont recommend you to switch VO to Expert mode, there can be problems in
> the future between VO Attribute and SQL column mapping. Also if you are
> using Java Impl classes for VO's, you can get not synchronized attributes
> while in Expert mode. Its better you can define SQL statement directly on
> transient attribute in Expression field.
>> Regarding the post-query,(using for getting the description field
>> which is in another table such as viewing the name of department when
>> there is only department_id in the VO of employee) as you now we have
>> 2 common ways to handle that first is to use two EO that there is an
>> association between them which one of them is updatable and the other
>> is just for reference and presenting the description field.
>> the other ways which of course is not very good is using a transient
>> field and override the get method for it in order to return the
>> description.
>> The way that I want to present is totally different from two mentioned
>> methods, I have not see this method any where in any
>> blog,forum,official or unofficial document;So I decided to present
>> this method and I would be appreciated if you, as a professional
>> developer, scrutinize this method to give me and others the cons and
>> pros.
>> In this method, for any description fields we would add a transient
>> field in the view ( it is not important that the VO is readonly or is
>> based on the EO)for example we would add the transient field
>> testDescription in the VO. next, in the query for the view we need to
>> change the query (if it is based on the EO we have to choose expert in
>> the sql mode) and add the blew to the select query
>> (select descritption form example_table where
>> example_table.id=viewquerytable.id) as testDescription
>> it is obvious that in this way the description would come along with
>> the query itself so there is not any extra round-trip to DB for
>> querying the description and also there is no need to add any extra EO
>> and Association for getting the description field.
>> I have add a sample,to see it in action (pls use the application
>> module tester as I have not add any page.)the sample is using the hr
>> schema.
>> --
>> You received this message because you are subscribed to the ADF Enterprise
>> Methodology Group (http://groups.google.com/group/adf-methodology). To
>> unsubscribe send email to adf-methodology+unsubscribe@googlegroups.com<adf-methodology%2Bunsubscribe@ googlegroups.com>
> --
> You received this message because you are subscribed to the ADF Enterprise
> Methodology Group (http://groups.google.com/group/adf-methodology). To
> unsubscribe send email to adf-methodology+unsubscribe@googlegroups.com<adf-methodology%2Bunsubscribe@ googlegroups.com>
> >(select descritption form example_table where
> example_table.id=viewquerytable.id) as testDescription
That is something we java people think is okay but the DBA's/performance
folks frown upon. Because your query would have a drastically different and
more expensive explain plan this way.
It might just save the network round trips to the DB but it's still an
inline query and to be avoided as far as possible IMHO.
>also there is no need to add any extra EO
> >and Association for getting the description field.
By the way, I think it's a best practice to have a good model with all
entities and associations defined. It's a one time cost that actually saves
time and effort in the long run and gives you a nice, clean and performant
code. Apart from increased reusability, you also have the benefits offered
by ADF features like association consistency.
JV
On Sat, Oct 31, 2009 at 12:34 PM, Andrejus Baranovskis <
> I was investigating this approach before and I had one problem - one page
> load it works fine, but when user is changing LOV value, description text
> wasn't required from database. At that point of time, it wasnt possible to
> set AutoSubmit on Attribute level in VO. Probably it will work now, with
> AutoSubmit set to true and Dependency enabled.
> I dont recommend you to switch VO to Expert mode, there can be problems in
> the future between VO Attribute and SQL column mapping. Also if you are
> using Java Impl classes for VO's, you can get not synchronized attributes
> while in Expert mode. Its better you can define SQL statement directly on
> transient attribute in Expression field.
>> Regarding the post-query,(using for getting the description field
>> which is in another table such as viewing the name of department when
>> there is only department_id in the VO of employee) as you now we have
>> 2 common ways to handle that first is to use two EO that there is an
>> association between them which one of them is updatable and the other
>> is just for reference and presenting the description field.
>> the other ways which of course is not very good is using a transient
>> field and override the get method for it in order to return the
>> description.
>> The way that I want to present is totally different from two mentioned
>> methods, I have not see this method any where in any
>> blog,forum,official or unofficial document;So I decided to present
>> this method and I would be appreciated if you, as a professional
>> developer, scrutinize this method to give me and others the cons and
>> pros.
>> In this method, for any description fields we would add a transient
>> field in the view ( it is not important that the VO is readonly or is
>> based on the EO)for example we would add the transient field
>> testDescription in the VO. next, in the query for the view we need to
>> change the query (if it is based on the EO we have to choose expert in
>> the sql mode) and add the blew to the select query
>> (select descritption form example_table where
>> example_table.id=viewquerytable.id) as testDescription
>> it is obvious that in this way the description would come along with
>> the query itself so there is not any extra round-trip to DB for
>> querying the description and also there is no need to add any extra EO
>> and Association for getting the description field.
>> I have add a sample,to see it in action (pls use the application
>> module tester as I have not add any page.)the sample is using the hr
>> schema.
>> --
>> You received this message because you are subscribed to the ADF Enterprise
>> Methodology Group (http://groups.google.com/group/adf-methodology). To
>> unsubscribe send email to adf-methodology+unsubscribe@googlegroups.com<adf-methodology%2Bunsubscribe@ googlegroups.com>
> --
> You received this message because you are subscribed to the ADF Enterprise
> Methodology Group (http://groups.google.com/group/adf-methodology). To
> unsubscribe send email to adf-methodology+unsubscribe@googlegroups.com<adf-methodology%2Bunsubscribe@ googlegroups.com>
> > example_table.id=viewquerytable.id) as testDescription
> That is something we java people think is okay but the DBA's/performance
> folks frown upon. Because your query would have a drastically different and
> more expensive explain plan this way.
> It might just save the network round trips to the DB but it's still an
> inline query and to be avoided as far as possible IMHO.
> >also there is no need to add any extra EO
>> >and Association for getting the description field.
> By the way, I think it's a best practice to have a good model with all
> entities and associations defined. It's a one time cost that actually saves
> time and effort in the long run and gives you a nice, clean and performant
> code. Apart from increased reusability, you also have the benefits offered
> by ADF features like association consistency.
> JV
> On Sat, Oct 31, 2009 at 12:34 PM, Andrejus Baranovskis <
> andrejus.baranovs...@gmail.com> wrote:
>> Hi Amir,
>> I was investigating this approach before and I had one problem - one page
>> load it works fine, but when user is changing LOV value, description text
>> wasn't required from database. At that point of time, it wasnt possible to
>> set AutoSubmit on Attribute level in VO. Probably it will work now, with
>> AutoSubmit set to true and Dependency enabled.
>> I dont recommend you to switch VO to Expert mode, there can be problems in
>> the future between VO Attribute and SQL column mapping. Also if you are
>> using Java Impl classes for VO's, you can get not synchronized attributes
>> while in Expert mode. Its better you can define SQL statement directly on
>> transient attribute in Expression field.
>>> Regarding the post-query,(using for getting the description field
>>> which is in another table such as viewing the name of department when
>>> there is only department_id in the VO of employee) as you now we have
>>> 2 common ways to handle that first is to use two EO that there is an
>>> association between them which one of them is updatable and the other
>>> is just for reference and presenting the description field.
>>> the other ways which of course is not very good is using a transient
>>> field and override the get method for it in order to return the
>>> description.
>>> The way that I want to present is totally different from two mentioned
>>> methods, I have not see this method any where in any
>>> blog,forum,official or unofficial document;So I decided to present
>>> this method and I would be appreciated if you, as a professional
>>> developer, scrutinize this method to give me and others the cons and
>>> pros.
>>> In this method, for any description fields we would add a transient
>>> field in the view ( it is not important that the VO is readonly or is
>>> based on the EO)for example we would add the transient field
>>> testDescription in the VO. next, in the query for the view we need to
>>> change the query (if it is based on the EO we have to choose expert in
>>> the sql mode) and add the blew to the select query
>>> (select descritption form example_table where
>>> example_table.id=viewquerytable.id) as testDescription
>>> it is obvious that in this way the description would come along with
>>> the query itself so there is not any extra round-trip to DB for
>>> querying the description and also there is no need to add any extra EO
>>> and Association for getting the description field.
>>> I have add a sample,to see it in action (pls use the application
>>> module tester as I have not add any page.)the sample is using the hr
>>> schema.
>>> --
>>> You received this message because you are subscribed to the ADF
>>> Enterprise Methodology Group (
>>> http://groups.google.com/group/adf-methodology). To unsubscribe send
>>> email to adf-methodology+unsubscribe@googlegroups.com<adf-methodology%2Bunsubscribe@ googlegroups.com>
>> --
>> You received this message because you are subscribed to the ADF Enterprise
>> Methodology Group (http://groups.google.com/group/adf-methodology). To
>> unsubscribe send email to adf-methodology+unsubscribe@googlegroups.com<adf-methodology%2Bunsubscribe@ googlegroups.com>
> --
> You received this message because you are subscribed to the ADF Enterprise
> Methodology Group (http://groups.google.com/group/adf-methodology). To
> unsubscribe send email to adf-methodology+unsubscribe@googlegroups.com<adf-methodology%2Bunsubscribe@ googlegroups.com>
I noticed one of the screens in your presentation at OOW had exactly
this kind of behaviour - e.g. once you'd chosen an ID from an LOV on
Requester Provider there was a description field on the main page that
had been populated. How was that done? (if you don't mind me
asking ;-)
<andrejus.baranovs...@gmail.com> wrote:
> Hi Amir,
> I was investigating this approach before and I had one problem - one page
> load it works fine, but when user is changing LOV value, description text
> wasn't required from database. At that point of time, it wasnt possible to
> set AutoSubmit on Attribute level in VO. Probably it will work now, with
> AutoSubmit set to true and Dependency enabled.
> I dont recommend you to switch VO to Expert mode, there can be problems in
> the future between VO Attribute and SQL column mapping. Also if you are
> using Java Impl classes for VO's, you can get not synchronized attributes
> while in Expert mode. Its better you can define SQL statement directly on
> transient attribute in Expression field.
> > Regarding the post-query,(using for getting the description field
> > which is in another table such as viewing the name of department when
> > there is only department_id in the VO of employee) as you now we have
> > 2 common ways to handle that first is to use two EO that there is an
> > association between them which one of them is updatable and the other
> > is just for reference and presenting the description field.
> > the other ways which of course is not very good is using a transient
> > field and override the get method for it in order to return the
> > description.
> > The way that I want to present is totally different from two mentioned
> > methods, I have not see this method any where in any
> > blog,forum,official or unofficial document;So I decided to present
> > this method and I would be appreciated if you, as a professional
> > developer, scrutinize this method to give me and others the cons and
> > pros.
> > In this method, for any description fields we would add a transient
> > field in the view ( it is not important that the VO is readonly or is
> > based on the EO)for example we would add the transient field
> > testDescription in the VO. next, in the query for the view we need to
> > change the query (if it is based on the EO we have to choose expert in
> > the sql mode) and add the blew to the select query
> > (select descritption form example_table where
> > example_table.id=viewquerytable.id) as testDescription
> > it is obvious that in this way the description would come along with
> > the query itself so there is not any extra round-trip to DB for
> > querying the description and also there is no need to add any extra EO
> > and Association for getting the description field.
> > I have add a sample,to see it in action (pls use the application
> > module tester as I have not add any page.)the sample is using the hr
> > schema.
> > --
> > You received this message because you are subscribed to the ADF Enterprise
> > Methodology Group (http://groups.google.com/group/adf-methodology). To
> > unsubscribe send email to adf-methodology+unsubscribe@googlegroups.com<adf-methodology%2Bunsubscribe@ googlegroups.com>
>>It should work through expression, because at the end its the same - it
just injects into SQL >>statement. For me it works.
Maybe Amir used the wrong kind of 'expression' field.
He needs to check the 'mapped to column or sql' in the VO attribute
properties.
Also check 'selected in query'
Then specify that inline query in the box meant for 'SQL expression' (under
Query Column section)
JV
On Sat, Oct 31, 2009 at 1:35 PM, Andrejus Baranovskis <
andrejus.baranovs...@gmail.com> wrote:
> It should work through expression, because at the end its the same - it
> just injects into SQL statement. For me it works.
> However, as JV says, its recommended to follow documented approach with
> associations.
>> > example_table.id=viewquerytable.id) as testDescription
>> That is something we java people think is okay but the DBA's/performance
>> folks frown upon. Because your query would have a drastically different and
>> more expensive explain plan this way.
>> It might just save the network round trips to the DB but it's still an
>> inline query and to be avoided as far as possible IMHO.
>> >also there is no need to add any extra EO
>>> >and Association for getting the description field.
>> By the way, I think it's a best practice to have a good model with all
>> entities and associations defined. It's a one time cost that actually saves
>> time and effort in the long run and gives you a nice, clean and performant
>> code. Apart from increased reusability, you also have the benefits offered
>> by ADF features like association consistency.
>> JV
>> On Sat, Oct 31, 2009 at 12:34 PM, Andrejus Baranovskis <
>> andrejus.baranovs...@gmail.com> wrote:
>>> Hi Amir,
>>> I was investigating this approach before and I had one problem - one page
>>> load it works fine, but when user is changing LOV value, description text
>>> wasn't required from database. At that point of time, it wasnt possible to
>>> set AutoSubmit on Attribute level in VO. Probably it will work now, with
>>> AutoSubmit set to true and Dependency enabled.
>>> I dont recommend you to switch VO to Expert mode, there can be problems
>>> in the future between VO Attribute and SQL column mapping. Also if you are
>>> using Java Impl classes for VO's, you can get not synchronized attributes
>>> while in Expert mode. Its better you can define SQL statement directly on
>>> transient attribute in Expression field.
>>>> Regarding the post-query,(using for getting the description field
>>>> which is in another table such as viewing the name of department when
>>>> there is only department_id in the VO of employee) as you now we have
>>>> 2 common ways to handle that first is to use two EO that there is an
>>>> association between them which one of them is updatable and the other
>>>> is just for reference and presenting the description field.
>>>> the other ways which of course is not very good is using a transient
>>>> field and override the get method for it in order to return the
>>>> description.
>>>> The way that I want to present is totally different from two mentioned
>>>> methods, I have not see this method any where in any
>>>> blog,forum,official or unofficial document;So I decided to present
>>>> this method and I would be appreciated if you, as a professional
>>>> developer, scrutinize this method to give me and others the cons and
>>>> pros.
>>>> In this method, for any description fields we would add a transient
>>>> field in the view ( it is not important that the VO is readonly or is
>>>> based on the EO)for example we would add the transient field
>>>> testDescription in the VO. next, in the query for the view we need to
>>>> change the query (if it is based on the EO we have to choose expert in
>>>> the sql mode) and add the blew to the select query
>>>> (select descritption form example_table where
>>>> example_table.id=viewquerytable.id) as testDescription
>>>> it is obvious that in this way the description would come along with
>>>> the query itself so there is not any extra round-trip to DB for
>>>> querying the description and also there is no need to add any extra EO
>>>> and Association for getting the description field.
>>>> I have add a sample,to see it in action (pls use the application
>>>> module tester as I have not add any page.)the sample is using the hr
>>>> schema.
>>>> --
>>>> You received this message because you are subscribed to the ADF
>>>> Enterprise Methodology Group (
>>>> http://groups.google.com/group/adf-methodology). To unsubscribe send
>>>> email to adf-methodology+unsubscribe@googlegroups.com<adf-methodology%2Bunsubscribe@ googlegroups.com>
>>> --
>>> You received this message because you are subscribed to the ADF
>>> Enterprise Methodology Group (
>>> http://groups.google.com/group/adf-methodology). To unsubscribe send
>>> email to adf-methodology+unsubscribe@googlegroups.com<adf-methodology%2Bunsubscribe@ googlegroups.com>
>> --
>> You received this message because you are subscribed to the ADF Enterprise
>> Methodology Group (http://groups.google.com/group/adf-methodology). To
>> unsubscribe send email to adf-methodology+unsubscribe@googlegroups.com<adf-methodology%2Bunsubscribe@ googlegroups.com>
> --
> You received this message because you are subscribed to the ADF Enterprise
> Methodology Group (http://groups.google.com/group/adf-methodology). To
> unsubscribe send email to adf-methodology+unsubscribe@googlegroups.com<adf-methodology%2Bunsubscribe@ googlegroups.com>
> I noticed one of the screens in your presentation at OOW had exactly
> this kind of behaviour - e.g. once you'd chosen an ID from an LOV on
> Requester Provider there was a description field on the main page that
> had been populated. How was that done? (if you don't mind me
> asking ;-)
> Simon
> On Oct 31, 12:34 pm, Andrejus Baranovskis
> <andrejus.baranovs...@gmail.com> wrote:
> > Hi Amir,
> > I was investigating this approach before and I had one problem - one page
> > load it works fine, but when user is changing LOV value, description text
> > wasn't required from database. At that point of time, it wasnt possible
> to
> > set AutoSubmit on Attribute level in VO. Probably it will work now, with
> > AutoSubmit set to true and Dependency enabled.
> > I dont recommend you to switch VO to Expert mode, there can be problems
> in
> > the future between VO Attribute and SQL column mapping. Also if you are
> > using Java Impl classes for VO's, you can get not synchronized attributes
> > while in Expert mode. Its better you can define SQL statement directly on
> > transient attribute in Expression field.
> > > Regarding the post-query,(using for getting the description field
> > > which is in another table such as viewing the name of department when
> > > there is only department_id in the VO of employee) as you now we have
> > > 2 common ways to handle that first is to use two EO that there is an
> > > association between them which one of them is updatable and the other
> > > is just for reference and presenting the description field.
> > > the other ways which of course is not very good is using a transient
> > > field and override the get method for it in order to return the
> > > description.
> > > The way that I want to present is totally different from two mentioned
> > > methods, I have not see this method any where in any
> > > blog,forum,official or unofficial document;So I decided to present
> > > this method and I would be appreciated if you, as a professional
> > > developer, scrutinize this method to give me and others the cons and
> > > pros.
> > > In this method, for any description fields we would add a transient
> > > field in the view ( it is not important that the VO is readonly or is
> > > based on the EO)for example we would add the transient field
> > > testDescription in the VO. next, in the query for the view we need to
> > > change the query (if it is based on the EO we have to choose expert in
> > > the sql mode) and add the blew to the select query
> > > (select descritption form example_table where
> > > example_table.id=viewquerytable.id) as testDescription
> > > it is obvious that in this way the description would come along with
> > > the query itself so there is not any extra round-trip to DB for
> > > querying the description and also there is no need to add any extra EO
> > > and Association for getting the description field.
> > > I have add a sample,to see it in action (pls use the application
> > > module tester as I have not add any page.)the sample is using the hr
> > > schema.
> > > --
> > > You received this message because you are subscribed to the ADF
> Enterprise
> > > Methodology Group (http://groups.google.com/group/adf-methodology). To
> > > unsubscribe send email to adf-methodology+unsubscribe@googlegroups.com<adf-methodology%2Bunsubscribe@ googlegroups.com>
> <adf-methodology%2Bunsubscribe@googlegroups.com<adf-methodology%252Bunsubsc ribe@googlegroups.com>
> --
> You received this message because you are subscribed to the ADF Enterprise
> Methodology Group (http://groups.google.com/group/adf-methodology). To
> unsubscribe send email to adf-methodology+unsubscribe@googlegroups.com<adf-methodology%2Bunsubscribe@ googlegroups.com>
Another advantage to using associations between EOs is storage. This
isn't too bad with a single short description field, but it's
something seriously to consider in queries with a larger number/larger
size of reference columns.
Let's suppose that, instead of a 25-byte department name field, you
had a total of 1000 bytes of reference data per row (not really all
that much, when you think about it). And suppose that, on average,
1000 employees corresponded to each department (a pretty large
company, but this could of course come up in non-HR situations), that
they're divided up into 15 departments, and that the average user
session involves querying about 3000 rows.
How much middle-tier memory does it take *just* to hold the
departments data? If you use a reference EO with an association, at
most 15kB, per session--not too bad. If you make the department data a
SQL-only attribute, though, it has to be stored for *each* employees
row, for a total of 3MB, per session--pretty serious resource
consumption.
Better still--make EmployeesView.DepartmentId a lov-based attribute,
using an application-scoped shared application module instance. Then,
storing the departments data takes at most 15kb, *period* (not per-
session).
I also recommend using a reference entity usage in your view object to
manage reference description data for lookup fields.
I've seen a number of anti-patterns in this area and I'm still trying to
understand what approach would be more efficient than the above one which is
handled automatically for you by the ADF framework but during query as well
as foreign key attribute modification.
The Oracle-forms-style POST-QUERY approach causes more queries to be issued
to the database.
On Sat, Oct 31, 2009 at 4:59 PM, Avrom Roy-Faderman <
av...@avromroyfaderman.com> wrote:
> Another advantage to using associations between EOs is storage. This
> isn't too bad with a single short description field, but it's
> something seriously to consider in queries with a larger number/larger
> size of reference columns.
> Let's suppose that, instead of a 25-byte department name field, you
> had a total of 1000 bytes of reference data per row (not really all
> that much, when you think about it). And suppose that, on average,
> 1000 employees corresponded to each department (a pretty large
> company, but this could of course come up in non-HR situations), that
> they're divided up into 15 departments, and that the average user
> session involves querying about 3000 rows.
> How much middle-tier memory does it take *just* to hold the
> departments data? If you use a reference EO with an association, at
> most 15kB, per session--not too bad. If you make the department data a
> SQL-only attribute, though, it has to be stored for *each* employees
> row, for a total of 3MB, per session--pretty serious resource
> consumption.
> Better still--make EmployeesView.DepartmentId a lov-based attribute,
> using an application-scoped shared application module instance. Then,
> storing the departments data takes at most 15kb, *period* (not per-
> session).
> --
> You received this message because you are subscribed to the ADF Enterprise
> Methodology Group (http://groups.google.com/group/adf-methodology). To
> unsubscribe send email to adf-methodology+unsubscribe@googlegroups.com<adf-methodology%2Bunsubscribe@ googlegroups.com>
|
