<div dir="ltr"><div><div><div><div>Hi All,<br><br></div>Recently I had a task of performance improvement in one of our network related flows and had some hard time following our DAL code and one of the outcomes of the task was defining a couple of new quite simple, but neat queries.<br>When I came to coding those new queries I remembered how hard was following the existing DAL code, I decided to make my own new methods clearer. So I created [1] and [2] patches. <br><br>Everything is quite standard there beside the fact that they do not use any stored procedure, but use SQL directly, IMHO by that they save time that I spent in trying to follow what a DAO method does. Looking into the method code you get the understanding of what this method is all about:<br><ul><li>no looking for a stored procedure name that is buried in the DAO class hierarchy<br></li><li>no looking for the SP definition</li></ul></div><div>So I&#39;d like to propose moving towards this approach in general in all cases when nothing beyond a simple SQL is needed (no stored procedure programming language is needed).<br>From my experience with the performance improvement task it looks like people avoid adding new queries for a specific need of a flow, instead they use the existing general ones (e.g. dao.getAllForX()) and do the actual join in the bll code.<br>IMHO the proposed approach would simplify adding new specific queries and by that would prevent a decent part of performance issues in the future.<br><br></div><div>I do not propose changing all existing SP&#39;s to inline queries in a once, but to allow adding new queries this way. Also we might consider converting relatively simple SP&#39;s to inline SQL statements later in a graduate way.<br></div><br>[1] - <a href="https://gerrit.ovirt.org/#/c/74456">https://gerrit.ovirt.org/#/c/74456</a><br>[2] - <a href="https://gerrit.ovirt.org/#/c/74458">https://gerrit.ovirt.org/#/c/74458</a><br><br></div>Regards,<br></div>Yevgeny<br></div>