<div dir="ltr"><div class="gmail_default" style="font-size:large"><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jul 18, 2017 at 8:56 AM, Yedidyah Bar David <span dir="ltr">&lt;<a href="mailto:didi@redhat.com" target="_blank">didi@redhat.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Tue, Jul 18, 2017 at 1:29 AM, Martin Perina &lt;<a href="mailto:mperina@redhat.com">mperina@redhat.com</a>&gt; wrote:<br>
&gt; Hello,<br>
&gt;<br>
&gt; to make things completely clear: any developer which will perform any<br>
&gt; changes around permissions tables need to use only predefined stored<br>
&gt; procedures for permissions handling. If for some reason direct SQL update is<br>
&gt; performed, then materialized view will not be refreshed until some<br>
&gt; permission stored procedure is called, which could cause strange results.<br>
<br>
</span>Isn&#39;t it possible to prevent such accidents somehow?<br>
<br>
E.g., is it possible that:<br>
1. We rename current table (&quot;permissions&quot;) to some &quot;private&quot;<br>
name (e.g. &quot;permissions_tab&quot;)<br></blockquote><div><div style="font-size:large" class="gmail_default">​This is possible ​</div><br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
2. We create the materialized view having the name of the<br>
original table (&quot;permissions&quot;)<br></blockquote><div><br><div style="font-size:large" class="gmail_default">​The MV replaces the views that uses the permissions table.<br></div><div style="font-size:large" class="gmail_default">The plan is to rename the original view to something else and have the created MV with the original view name  <br></div><br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
3. We do what&#39;s needed (?) so that direct inserts/updates/deletes<br>
on the view either fail or do the right thing.<br></blockquote><div><br><div style="font-size:large;display:inline" class="gmail_default">​See my answer in 1)<br>​</div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5"><br>
&gt;<br>
&gt; Eli has already removed all such code within patch [3], so this is just a<br>
&gt; warning for future.<br>
&gt;<br>
&gt; Thanks<br>
&gt;<br>
&gt; Martin<br>
&gt;<br>
&gt;<br>
&gt; On Mon, Jul 17, 2017 at 9:47 PM, Eli Mesika &lt;<a href="mailto:emesika@redhat.com">emesika@redhat.com</a>&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; Materialized Views [1] can be used to reduce query time on complex queries<br>
&gt;&gt; with low data update<br>
&gt;&gt;<br>
&gt;&gt; The first candidates to use this feature are all the *permission* views<br>
&gt;&gt;<br>
&gt;&gt; There is already a RFE [2] opened for that.<br>
&gt;&gt;<br>
&gt;&gt; Please make sure that each call that handles the permissions table data is<br>
&gt;&gt; using the corresponding SP in dbscripts/multi_level_<wbr>administration.sql<br>
&gt;&gt; No direct access to the permissions table is allowed !<br>
&gt;&gt;<br>
&gt;&gt; In case that a direct access to the permissions table is used, you should<br>
&gt;&gt; replace the code in a call to the corresponding SP as you can see in [3]<br>
&gt;&gt;<br>
&gt;&gt; A direct use that will not be replaced with a call to the corresponding SP<br>
&gt;&gt; may cause that direct changes to the permissions table will not be reflected<br>
&gt;&gt; in the<br>
&gt;&gt; *permission* Materialized Views and the views will remain dirty until a<br>
&gt;&gt; change that is calling one of the SPs that handle the data of the<br>
&gt;&gt; permissions table is issued and cause the Materialized Views to be refreshed<br>
&gt;&gt;<br>
&gt;&gt; Please check your code for direct use of the permissions table and consult<br>
&gt;&gt; with me if you have any questions or issues.<br>
&gt;&gt;<br>
&gt;&gt; Thanks<br>
&gt;&gt;<br>
&gt;&gt; Eli Mesika<br>
&gt;&gt;<br>
&gt;&gt; [1] <a href="https://wiki.postgresql.org/wiki/Materialized_Views" rel="noreferrer" target="_blank">https://wiki.postgresql.org/<wbr>wiki/Materialized_Views</a><br>
&gt;&gt; [2] <a href="https://bugzilla.redhat.com/show_bug.cgi?id=1470991" rel="noreferrer" target="_blank">https://bugzilla.redhat.com/<wbr>show_bug.cgi?id=1470991</a><br>
&gt;&gt; [3] <a href="https://gerrit.ovirt.org/#/c/79287/" rel="noreferrer" target="_blank">https://gerrit.ovirt.org/#/c/<wbr>79287/</a><br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; ______________________________<wbr>_________________<br>
&gt;&gt; Devel mailing list<br>
&gt;&gt; <a href="mailto:Devel@ovirt.org">Devel@ovirt.org</a><br>
&gt;&gt; <a href="http://lists.ovirt.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.ovirt.org/<wbr>mailman/listinfo/devel</a><br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; ______________________________<wbr>_________________<br>
&gt; Devel mailing list<br>
&gt; <a href="mailto:Devel@ovirt.org">Devel@ovirt.org</a><br>
&gt; <a href="http://lists.ovirt.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.ovirt.org/<wbr>mailman/listinfo/devel</a><br>
<br>
<br>
<br>
</div></div><span class="HOEnZb"><font color="#888888">--<br>
Didi<br>
</font></span></blockquote></div><br></div></div>