clean package by sunary · Pull Request #66 · sunary/sqlize · GitHub
Skip to content

clean package#66

Merged
sunary merged 1 commit into
masterfrom
clean-package
Mar 1, 2026
Merged

clean package#66
sunary merged 1 commit into
masterfrom
clean-package

Conversation

@sunary

@sunary sunary commented Mar 1, 2026

Copy link
Copy Markdown
Owner

Summary by CodeRabbit

  • Bug Fixes

    • Corrected typo in Avro schema export function naming.
  • Chores

    • Updated CI to test against Go 1.25.x instead of 1.13.x and 1.14.x.
    • Reorganized internal module structure for improved maintainability.
  • Tests

    • Updated Avro schema tests to reflect naming corrections.

@coderabbitai

coderabbitai Bot commented Mar 1, 2026

Copy link
Copy Markdown

@coderabbitai coderabbitai Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)
sqlbuilder/builder.go (1)

341-342: ⚠️ Potential issue | 🟠 Major

Bug: tagIsNull incorrectly sets at.IsNotNull = true.

The case for tagIsNull at line 341 sets at.IsNotNull = true, which is the opposite of the intended behavior. It should set at.IsNull = true.

🐛 Proposed fix
 			case normTag == tagIsNull:
-				at.IsNotNull = true
+				at.IsNull = true
 
 			case normTag == tagIsNotNull:
 				at.IsNotNull = true
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@sqlbuilder/builder.go` around lines 341 - 342, The case handling the
normalized tag "tagIsNull" incorrectly sets at.IsNotNull = true; update that
branch so it sets at.IsNull = true instead (locate the switch/case that handles
normTag == tagIsNull in sqlbuilder, change the assignment on the at struct
accordingly), and run/update any unit tests that assert null vs not-null
behavior for the related function/methods to ensure the fix is covered.
🧹 Nitpick comments (2)
sqlize.go (1)

254-269: Consider keeping a deprecated ArvoSchema wrapper for compatibility.

Renaming this exported method is source-breaking. A wrapper can preserve backward compatibility while moving callers forward.

Proposed backward-compatible wrapper
+// Deprecated: use AvroSchema.
+func (s Sqlize) ArvoSchema(needTables ...string) []string {
+	return s.AvroSchema(needTables...)
+}
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@sqlize.go` around lines 254 - 269, Add a backward-compatible wrapper named
ArvoSchema that simply delegates to the existing AvroSchema method to avoid
breaking callers: implement a new exported method ArvoSchema(needTables
...string) []string which calls and returns s.AvroSchema(needTables...), and
mark it with a clear deprecation comment (e.g., "// Deprecated: ArvoSchema is
deprecated; use AvroSchema instead.") so callers are guided to migrate while
preserving compatibility.
export/avro/builder.go (1)

12-13: Consider a deprecated compatibility shim for the renamed constructor.

Renaming an exported function is source-breaking for external callers. A temporary wrapper keeps upgrade friction low.

Proposed backward-compatible shim
+// Deprecated: use NewAvroSchema.
+func NewArvoSchema(table element.Table) *RecordSchema {
+	return NewAvroSchema(table)
+}
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@export/avro/builder.go` around lines 12 - 13, You renamed the exported
constructor to NewAvroSchema which is source-breaking for callers; add a
deprecated compatibility wrapper using the previous exported function name (the
old constructor) that simply calls NewAvroSchema(table) and returns
*RecordSchema, mark it with a deprecation comment, and update any internal call
sites to use NewAvroSchema where appropriate so external users can migrate
gracefully.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@sqlize_test.go`:
- Line 991: The AvroSchema test assertion indexes got[0] and tt.want[0] without
verifying slice lengths, which can panic; update the condition around the
s.AvroSchema call to first ensure got and tt.want are non-nil and have length >
0 (e.g. check len(got) > 0 && len(tt.want) > 0) before calling
areEqualJSON(got[0], tt.want[0]), and otherwise assert nil/empty expectations
appropriately so the test never accesses index 0 on an empty slice.

---

Outside diff comments:
In `@sqlbuilder/builder.go`:
- Around line 341-342: The case handling the normalized tag "tagIsNull"
incorrectly sets at.IsNotNull = true; update that branch so it sets at.IsNull =
true instead (locate the switch/case that handles normTag == tagIsNull in
sqlbuilder, change the assignment on the at struct accordingly), and run/update
any unit tests that assert null vs not-null behavior for the related
function/methods to ensure the fix is covered.

---

Nitpick comments:
In `@export/avro/builder.go`:
- Around line 12-13: You renamed the exported constructor to NewAvroSchema which
is source-breaking for callers; add a deprecated compatibility wrapper using the
previous exported function name (the old constructor) that simply calls
NewAvroSchema(table) and returns *RecordSchema, mark it with a deprecation
comment, and update any internal call sites to use NewAvroSchema where
appropriate so external users can migrate gracefully.

In `@sqlize.go`:
- Around line 254-269: Add a backward-compatible wrapper named ArvoSchema that
simply delegates to the existing AvroSchema method to avoid breaking callers:
implement a new exported method ArvoSchema(needTables ...string) []string which
calls and returns s.AvroSchema(needTables...), and mark it with a clear
deprecation comment (e.g., "// Deprecated: ArvoSchema is deprecated; use
AvroSchema instead.") so callers are guided to migrate while preserving
compatibility.

ℹ️ Review info

Configuration used: defaults

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 2a4ba85 and 477809b.

📒 Files selected for processing (16)
  • .travis.yml
  • element/column.go
  • element/migration.go
  • export/avro/builder.go
  • options.go
  • sqlbuilder/builder.go
  • sqlbuilder/options.go
  • sqlize.go
  • sqlize_test.go
  • sqlparser/mysql.go
  • sqlparser/parser.go
  • sqlparser/postgresql.go
  • sqlparser/sqlite.go
  • sqltemplates/ddl.go
  • sqltemplates/option.go
  • sqltemplates/type.go

Comment thread sqlize_test.go

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟡 Minor

Guard slice access in the Avro assertion to avoid panic.

The current check can index got[0]/tt.want[0] without validating lengths first, which can panic and hide assertion intent.

Safer assertion pattern
-			if got := s.AvroSchema(tt.args.needTables...); (got != nil || tt.want != nil) && !areEqualJSON(got[0], tt.want[0]) {
+			if got := s.AvroSchema(tt.args.needTables...); len(got) != len(tt.want) ||
+				(len(got) > 0 && !areEqualJSON(got[0], tt.want[0])) {
 				t.Errorf("AvroSchema() mysql got = \n%v,\nexpected = \n%v", got, tt.want)
 			}
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@sqlize_test.go` at line 991, The AvroSchema test assertion indexes got[0] and
tt.want[0] without verifying slice lengths, which can panic; update the
condition around the s.AvroSchema call to first ensure got and tt.want are
non-nil and have length > 0 (e.g. check len(got) > 0 && len(tt.want) > 0) before
calling areEqualJSON(got[0], tt.want[0]), and otherwise assert nil/empty
expectations appropriately so the test never accesses index 0 on an empty slice.

@sunary sunary merged commit a7b548e into master Mar 1, 2026
2 checks passed
@sunary sunary deleted the clean-package branch March 1, 2026 03:02
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant