Feature: add Namer-driven column name lookup in schema field retrieval

[cmmoran]

• Do only one thing
• Non breaking API changes
• Tested - (yes. tested, I have not modified the gorm test cases)

What did this pull request do?

Currently, func (schema *Schema) LookUpField(name string) *Field checks:

• schema.FieldsByDBName
• schema.FieldsByName

and returns nil in the event that the field is not found in either case.

This enhances the behavior slightly. The original function is intact, in addition, if a schema.Namer has been defined, schema.FieldsByDBName is checked once more with the namer-driven column name.

User Case Description

Admittedly, this is quite self-serving. I've written heavily modified so much that it may as well not be a fork a gorm-oracle plugin. One of the many idiosyncrasies of oracle is that it stores all non-quoted, non-reserved-word identifiers as UPPERCASE. This breaks from sanity, logic, good common-sense, most language conventions, and gorm's default handling. If a column: tag is set for a field, this value is used (without Namer.ColumnName transformation) exactly as-is if the NamingCaseSensitive flag is set to false. If NamingCaseSensitive is set to true, gorm will quote the exact value of the column: tag. This wouldn't be an issue if oracle treated "foo" and foo the same. But, alas, oracle does not equate "foo" and FOO. However, "FOO" and FOO are considered "same" in oracle-ese. It bears noting that my gorm-oracle plugin provides the necessary schema.Namer logic that will handle the proper quote handling of identifiers that must be quoted (reserved words, user-provided quoted identifiers, etc). But without this change, the column metadata returned by oracle (and used by gorm.Scan) will never match the column:foo unless the tag is specified column:FOO.

"Why not just use column:FOO?"

Because it's ugly. I don't want to litter my code with column:SOME_STUPID_UPPER_CASE_NAME. It's also unnecessary to require two different structures for oracle and any other db when one structure would work just fine; if gorm supported it.

As an aside, for some weird reason, gorm does not include a "default naming case" option. When NoLowerCase is set to true, the DBName becomes something useless less-than-useful: UserID field name becomes USERID in oracle with default gorm. Arguably, this can easily be solved by gorm providing a default case handler: ScreamingSnakeCase, CamelCase (or PascalCase whichever you prefer), or SnakeCase or whatever. This would allow users to avoid forcibly setting the column: tag when it otherwise would not have been necessary had gorm provided a means to convert the field name with more precision.

"Why not just omit column: altogether and live with gorm's default naming?"

No.

[propel-code-bot]

Enhance LookUpField with Namer-Driven Column Name Lookup

This PR augments the schema.Schema.LookUpField method to improve field resolution by introducing an additional lookup using the namer.ColumnName transformation if a schema.Namer is defined. The enhancement specifically targets cases where a field is not found by FieldsByDBName or FieldsByName; the code then uses the Namer interface to generate a transformed column name (accounting for DB-specific naming idiosyncrasies) and checks again in FieldsByDBName. This addresses difficulties with DBs such as Oracle, where default identifier casing can diverge from application field naming conventions, particularly when integrating custom plugins that define specialized naming logic.

Key Changes

• Extended schema.Schema.LookUpField to check schema.FieldsByDBName a second time using the result of schema.namer.ColumnName(schema.Table, name) if the initial lookups fail and schema.namer is present.
• Added guard conditions to avoid unnecessary lookup if namer.ColumnName returns an empty string or the same value as the original.
• Ensured the enhancement is non-breaking and does not alter existing behavior for databases or users not utilizing custom Namer logic.

Affected Areas

• schema/schema.go: Only the LookUpField method was modified.

This summary was automatically generated by @propel-code-bot