Issue 650 - Updated LocationLevel getOne to handle custom units

[zack-rma]

Fixes #650 - Updated LocationLevel getOne to handle custom units and unit systems

[zack-rma]

I also discovered that the effective date query parameter for getOne is used as the end date in the PL/SQL call. Effectively, any date provided that is after the effective date of the target locationLevel will work to find that locationLevel. This also results in the returned effective date being set to the provided value, not the DB value.

Not sure about the impact of this, maybe it should get its own issue? @MikeNeilson

[MikeNeilson]

I also discovered that the effective date query parameter for getOne is used as the end date in the PL/SQL call. Effectively, any date provided that is after the effective date of the target locationLevel will work to find that locationLevel. This also results in the returned effective date being set to the provided value, not the DB value.

Not sure about the impact of this, maybe it should get its own issue? @MikeNeilson

Sorry, I've re-read this several times and I'm still having difficulty following the issue; I mean it seems like an issue but it's not mapping in my head. Any way to make a simple diagram, flow chart, just plain example data where the issue would be more obvious to myself and others.?

[adamkorynta]

If I'm following correctly: lets say I pass in today's date, it'll give me back the loc level value from the last effective date (let's say last year), but the DTO returns today's date as the effective date.

[MikeNeilson]

Ah. I see, yeah the correct effective date should be what's in the DTO.

[zack-rma]

Rebased to fix build errors.

[zack-rma]

Rebased to fix build issue

[zack-rma]

Build errors appear to be unrelated to these changes