<div dir="ltr">No, your instincts are right.  It would be much better not to hit the database again; in a robust multi-webhead setup, the database server is a separate machine, so you pay network time for every database call.  In this case, I didn't want to break the interface of that function, and that function doesn't know uitype.  I took on some technical debt to keep my merge cost lower.  One possible way to split the difference would be to put a static variable in that function and fill that cache with tablename => uitype.  That would at least get you down to one extra database call per request, from one per picklist.</div>
<div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, May 15, 2013 at 2:42 AM, Alan Lord <span dir="ltr"><<a href="mailto:alanslists@gmail.com" target="_blank">alanslists@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 14/05/13 18:29, Adam Heinz wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
*SHOW COLUMNS FROM vtiger_$tablename LIKE 'sortorderid*<br>
</blockquote>
<br>
That's a neat idea, thanks.<br>
<br>
My reason for thinking of making a decision earlier in the flow in getPicklistOptions() is that "$this" already has the uitype value so I could choose the right query without having to first make *another* query to the db to find out.<br>

<br>
But maybe it really makes little difference in the overall scheme of things?<br>
<br>
Al<br>
<br>
<br>
<br>
______________________________<u></u>_________________<br>
<a href="http://www.vtiger.com/" target="_blank">http://www.vtiger.com/</a><br>
</blockquote></div><br></div>