A new way for post-query (description field) without using the EO or get accessor pls give me your feedback.

[akhanof]

Dear All,

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.

http://groups.google.com/group/adf-methodology/web/postquerysample.zip

Thanks and regards,
Amir Khanof

[Andrejus Baranovskis]

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.

Regards,

Andrejus

2009/10/31 akhanof <amir....@gmail.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-methodolo...@googlegroups.com

--
Oracle ACE Director

My Blog - http://andrejusb.blogspot.com/
My JDev/ADF Samples list - http://andrejusb-samples.blogspot.com/

[amir hosein khanof]

Hi Andrejus,

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

[JV Singh]

>(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

[Andrejus Baranovskis]

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.

Andrejus

2009/10/31 JV Singh <jvs...@gmail.com>

[Simon Haslam]

Andrejus

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.
>
> Regards,
> Andrejus
>

> 2009/10/31 akhanof <amir.kha...@gmail.com>

> > unsubscribe send email to adf-methodolo...@googlegroups.com<adf-methodology%2Bunsu...@googlegroups.com>
>
> --
> Oracle ACE Director
>
> My Blog -http://andrejusb.blogspot.com/

[JV Singh]

>>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 

[Andrejus Baranovskis]

Hi Simon,

We are doing it same as JV Singh describes, through Associations between EO's.

Regards,

Andrejus

2009/10/31 Simon Haslam <Sim...@veriton.co.uk>

--
Oracle ACE Director

My Blog - http://andrejusb.blogspot.com/

[Avrom Roy-Faderman]

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).

[Steve Muench]

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.

--