<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Oct 21, 2014 at 6:40 AM, Rod Widdowson <span dir="ltr"><<a href="mailto:rdw@steadingsoftware.com" target="_blank">rdw@steadingsoftware.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I have been doing some housework and cleaning some TODOs.<br>
<br>The next is asks whether we 'use queryUsesStoredProcedure', and again I<br>
think that the answer is 'no'?<br></blockquote><div><br></div><div>AFAICT, that parameter is only used to throw an exception on validation if the database doesn't support stored procedures.</div><div>If that's all we want out of that parameter, it's easy functionality to port.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The last TODO is about moving hard wired defaults from the LDAP parsers into<br>
the bean definitions. This is not just a simple matter of adding some<br>
constants into beans because firstly there are non-custom-spring ways of<br>
setting up the beans, and secondly in many cases the beans are not ours -<br>
they belong to ldaptive.<br>
<br>
I'm thinking that the best solution is to have subclasses of the ldaptive<br>
beans with the defaults in place. But, I'm not 100% convinced:<br>
- It could be said that we are moving the defaults from one hard to find<br>
location to another.<br>
- And if people really want the fine control, then they will not be using<br>
our custom schema, they'll use Spring.<br></blockquote><div><br></div><div>Subclassing seems like a lot of effort. +1 for Scott's comment to just javadoc it.</div><div><br></div><div>--Daniel Fisher</div><div> </div></div></div></div>