Users - View-entity best practices guidelines

[Vinay Agarwal]

Hello,

 

I am trying to understand best practices guidelines about creating view-entity vs. pulling data out through getRelated methods. Is it a good practice to create a view-entity if an entity is commonly accessing a specific relation with another entity?

 

Thanks in advance,

Vinay Agarwal

 
_______________________________________________
Users mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/users

[David E. Jones]

The official best practice for this is: do whatever works best and/or is fastest.

There isn't any good rule for this that can always be followed. For example: it is usually fastest to use a view-entity to do a single round trip to the database rather than a query to get a list of results plus a query for each result (using getRelated or whatever).

There ARE exceptions to this. In order to handle a very large volume of results it is necessary for performance reasons to not have joins (view-entities) that are too wide. When you might get thousands or even millions (or perhaps even more...) results back, like in a Party search, you should not make the view-entity too wide. If there are many possibilities for different query parameters you should use a dynamic view entity like the find party service does and only include 2 categories of fields and their corresponding entities in it:

1. fields to constrain by
2. fields to sort/order by

Notice I did _not_ include fields to show to the user. Of course, it is different if you are doing reporting, then all results will be viewed and so you might as well include all fields to display in the view-entity as well.

In a user interface that shows results a page at a time with only 10 or 20 (or even 50 or 100) results at a time it is MUCH better to not include all fields that will be viewed only. It is better to do 10 or 20 or 100 additional queries (one per result actually displayed, using a view-entity if needed to get from multiple entities).

Why is this? Here's an example: you have a million customer records and want to search in them. If we did a static view-entity with all fields that we might want to search by, order by, or display we would force the database to create a MASSIVE temporary table, and the table would never fit into memory so it would have to be a disk-based temp table, and now we've crossed the line into requiring many minutes for the darn query to run. Slim down the same query given the 2 criteria above for fields to include, and it can get down to a few seconds plus a few seconds to get the additional data to display.

===============

That's just one example of a factor to consider with this. It is really fairly complicated and requires some experience to know what to do. And of course, like anything where performance is a factor doing profiling and knowing what the different things are doing in order to decide how to improve the speed (and to test to make sure you _have_ actually done so...) are very important.

So, the answer to this, as to many other questions is: it depends... That, of course, is just a saying bred from intellectual laziness that really means: more details are needed for a "solution".

-David


Vinay Agarwal wrote:

> Hello,
>
>  
>
> I am trying to understand best practices guidelines about creating
> view-entity vs. pulling data out through getRelated methods. Is it a
> good practice to create a view-entity if an entity is commonly accessing
> a specific relation with another entity?
>
>  
>
> Thanks in advance,
>
> Vinay Agarwal

 
_______________________________________________
Users mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/users

[Vinay Agarwal]

Thanks David. This answer is so useful that I am going to add this to Wiki.
Vinay

-----Original Message-----
From: [hidden email] [mailto:[hidden email]]
On Behalf Of David E Jones
Sent: Sunday, April 23, 2006 10:27 AM
To: OFBiz Users / Usage Discussion
Subject: Re: [OFBiz] Users - View-entity best practices guidelines


The official best practice for this is: do whatever works best and/or is
fastest.

There isn't any good rule for this that can always be followed. For example:
it is usually fastest to use a view-entity to do a single round trip to the
database rather than a query to get a list of results plus a query for each
result (using getRelated or whatever).

There ARE exceptions to this. In order to handle a very large volume of
results it is necessary for performance reasons to not have joins
(view-entities) that are too wide. When you might get thousands or even
millions (or perhaps even more...) results back, like in a Party search, you
should not make the view-entity too wide. If there are many possibilities
for different query parameters you should use a dynamic view entity like the
find party service does and only include 2 categories of fields and their
corresponding entities in it:

1. fields to constrain by
2. fields to sort/order by

Notice I did _not_ include fields to show to the user. Of course, it is
different if you are doing reporting, then all results will be viewed and so
you might as well include all fields to display in the view-entity as well.

In a user interface that shows results a page at a time with only 10 or 20
(or even 50 or 100) results at a time it is MUCH better to not include all
fields that will be viewed only. It is better to do 10 or 20 or 100
additional queries (one per result actually displayed, using a view-entity
if needed to get from multiple entities).

Why is this? Here's an example: you have a million customer records and want
to search in them. If we did a static view-entity with all fields that we
might want to search by, order by, or display we would force the database to
create a MASSIVE temporary table, and the table would never fit into memory
so it would have to be a disk-based temp table, and now we've crossed the
line into requiring many minutes for the darn query to run. Slim down the
same query given the 2 criteria above for fields to include, and it can get
down to a few seconds plus a few seconds to get the additional data to
display.

===============

That's just one example of a factor to consider with this. It is really
fairly complicated and requires some experience to know what to do. And of
course, like anything where performance is a factor doing profiling and
knowing what the different things are doing in order to decide how to
improve the speed (and to test to make sure you _have_ actually done so...)
are very important.

So, the answer to this, as to many other questions is: it depends... That,
of course, is just a saying bred from intellectual laziness that really
means: more details are needed for a "solution".

-David


Vinay Agarwal wrote:

> Hello,
>
>  
>
> I am trying to understand best practices guidelines about creating
> view-entity vs. pulling data out through getRelated methods. Is it a
> good practice to create a view-entity if an entity is commonly accessing
> a specific relation with another entity?
>
>  
>
> Thanks in advance,
>
> Vinay Agarwal

 
_______________________________________________
Users mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/users
 
_______________________________________________
Users mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/users