A couple of TODOs in the attributes code.

[Cantor, Scott]

On 10/21/14, 6:40 AM, "Rod Widdowson" <rdw at steadingsoftware.com> wrote:
>
>The first is about attribute value mapping in LDAP.  I think this ties
>back
>into the RDBMS mapping that Scot and I are looking at.  However it refers
>to
>new function "Do we want to do data mapping as we do for RDBMS?", and I
>think right now we can say "no".

No, I don't. I'm probably going to punt on the RDBMS half and give it to
you once I get the column renaming supported, and if you have time, that's
ok, but at this point I'm in "Scott needs it" mode, which means I don't
spend time on extra things I don't need.

>The next is asks whether we 'use queryUsesStoredProcedure', and again I
>think that the answer is 'no'?

Don't know what it does, but historically SPs are tricky to work with in
ODBC. Did it work before?

I had a concern about whether the mergeResults option in LDAP is making
sense. When I read the docs on that option in the schema, I couldn't map
that to what the Javadoc for the ldaptive class that it apparently
triggers the use of was saying. They didn't seem quite the same to me.

>I'm thinking that the best solution is to have subclasses of the ldaptive
>beans with the defaults in place.  But, I'm not 100% convinced:
>  - It could be said that we are moving the defaults from one hard to find
>location to another.
>  - And if people really want the fine control, then they will not be
>using
>our custom schema, they'll use Spring.

I don't think it's worth subclassing everything to get defaults. But I
think it would be useful to start documenting in the Javadoc anywhere that
we explicitly set defaults in the parsers.

-- Scott