Re: [ovirt-devel] Important changes in the Search Engine code
- Original Message -
From: Eli Mesika emes...@redhat.com
To: engine-de...@ovirt.org devel@ovirt.org
Sent: Wednesday, March 11, 2015 10:48:44 AM
Subject: [ovirt-devel] Important changes in the Search Engine code
Hi All
We had in the past many cases in which the search engine returned duplicate
records.
Most of those cases are not simple to resolve in the DB layer by changing the
query due to schema limitations.
We had decided to handle that by adding DISTINCT to the queries that the
search engine generates [1]
Wouldn't that cause some penalty for each query ? Each navigation between tabs
in
the UI will become slower now that the returned values need to be sorted, even
when
not required ?
However, we might have cases in which both DISTINCT and ORDER BY f({args})
(where f is a function call) is used
In that case, we will get SQL exception since the ORDER BY is applied on the
DISTINCT result that does not include f as a field.
I had prevented using DISTINCT in such cases [2]
That means that you still may got duplicates in such cases and then you
should handle it in the same method as in [3]
(basically returning the function result in the select as a computed field)
[1] https://gerrit.ovirt.org/#/c/31896
[2] https://gerrit.ovirt.org/#/c/38459
[3] https://gerrit.ovirt.org/#/c/36946
Thanks
Eli Mesika
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
[ovirt-devel] Important changes in the Search Engine code
Hi All
We had in the past many cases in which the search engine returned duplicate
records.
Most of those cases are not simple to resolve in the DB layer by changing the
query due to schema limitations.
We had decided to handle that by adding DISTINCT to the queries that the search
engine generates [1]
However, we might have cases in which both DISTINCT and ORDER BY f({args})
(where f is a function call) is used
In that case, we will get SQL exception since the ORDER BY is applied on the
DISTINCT result that does not include f as a field.
I had prevented using DISTINCT in such cases [2]
That means that you still may got duplicates in such cases and then you should
handle it in the same method as in [3]
(basically returning the function result in the select as a computed field)
[1] https://gerrit.ovirt.org/#/c/31896
[2] https://gerrit.ovirt.org/#/c/38459
[3] https://gerrit.ovirt.org/#/c/36946
Thanks
Eli Mesika
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] Important changes in the Search Engine code
- Original Message -
From: Moti Asayag masa...@redhat.com
To: Eli Mesika emes...@redhat.com
Cc: engine-de...@ovirt.org devel@ovirt.org
Sent: Wednesday, March 11, 2015 11:53:50 AM
Subject: Re: [ovirt-devel] Important changes in the Search Engine code
- Original Message -
From: Eli Mesika emes...@redhat.com
To: engine-de...@ovirt.org devel@ovirt.org
Sent: Wednesday, March 11, 2015 10:48:44 AM
Subject: [ovirt-devel] Important changes in the Search Engine code
Hi All
We had in the past many cases in which the search engine returned duplicate
records.
Most of those cases are not simple to resolve in the DB layer by changing
the
query due to schema limitations.
We had decided to handle that by adding DISTINCT to the queries that the
search engine generates [1]
Wouldn't that cause some penalty for each query ? Each navigation between
tabs in
the UI will become slower now that the returned values need to be sorted,
even when
not required ?
We had tested that for a while and the penalty is relatively small.
We surely can come with a better solution but it requires heavy schema changes
I think we can live with that
However, we might have cases in which both DISTINCT and ORDER BY f({args})
(where f is a function call) is used
In that case, we will get SQL exception since the ORDER BY is applied on
the
DISTINCT result that does not include f as a field.
I had prevented using DISTINCT in such cases [2]
That means that you still may got duplicates in such cases and then you
should handle it in the same method as in [3]
(basically returning the function result in the select as a computed field)
[1] https://gerrit.ovirt.org/#/c/31896
[2] https://gerrit.ovirt.org/#/c/38459
[3] https://gerrit.ovirt.org/#/c/36946
Thanks
Eli Mesika
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
