Add Query.ignoreColumn()

[StanAccy]

Add ability to ignore specific fields when mapping POJOs. The blanket "ignore mapping exceptions" option that was added actually hid defects since primitive values in the POJO were being initialized with incorrect values

[vertex-github]

Bump - can we get this merged in - is anything blocking it? (well, apart from the conflict now on PojoMetadata - that wasnt there when we submitted the PR)

[aaberg]

Sorry for replying to this so late. Is there a specific reason why you can't remove the column from the query?

[StanAccy]

It's been quite a while since I logged that ticket so I don't really recall the reasoning behind it. There was a reason though! If I had to guess it was likely so that I could issue a simple select * and ignore some columns for making the loading easier. I believe I implemented this in our local copy of sql2o but I'd have to load the repo to see what changes we made.

…

On Sat, Apr 13, 2024, 06:31 Lars Aaberg ***@***.***> wrote: Sorry for replying to this so late. Is there a specific reason why you can't remove the column from the query? — Reply to this email directly, view it on GitHub <#273 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAUCWLYOGORDXSAM4EJSKI3Y5ECRTAVCNFSM4DGYDFUKU5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TEMBVGM3DANJWGU3Q> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[aaberg]

Thanks. You are right; there is a use case here, although it is debatable if fetching columns that won't be used is good practice. I am thinking that maybe the existing columnMappings can be expanded to incorporate this feature instead, which I believe will result in a better API.

[StanAccy]

I think we considered that approach but found the simpler select * easier to leverage - again, its been several years and I dont recall the specifics anymore. I just took a look at the project where we used this - we used this a lot. The pattern was to "select * from table" via a Queryu.creaqteQueryWithParams() then leverage the automatic bean mapping to construct a domain entity in code via the query.executeAndFetch( DomainClass.class ); Im assuming (again, its been a while) that if we didnt ignore some fields, that the auto mapping would fail due to unmapped columns. We like the control of excluding specific fields - this way if new fields were added to the schema and we didnt update the code, then stuff would break (I think) Reading the code now after all these years I can clearly see whats going on, what we're loading and what we expect to be in the DB vs what we need to construct the domain entities in memory. It does seem to be query specific. Nick

…

On Sat, Apr 13, 2024 at 7:20 AM Lars Aaberg ***@***.***> wrote: Thanks. You are right; there is a use case here, although it is debatable if fetching columns that won't be used is good practice. I am thinking that maybe the existing columnMappings can be expanded to incorporate this feature instead, which I believe will result in a better API. — Reply to this email directly, view it on GitHub <#273 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAUCWL7S6E6V56R7AX4IKX3Y5EIHDAVCNFSM4DGYDFUKU5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TEMBVGM3DCNZVG42A> . You are receiving this because you authored the thread.Message ID: ***@***.***>