Skip to content

Conversation

@tothandras
Copy link
Contributor

@tothandras tothandras commented Apr 5, 2025

Summary by CodeRabbit

  • New Features
    • Introduced a new “Instance Type” attribute for add-ons, allowing configuration as either “single” or “multiple” (default is “single”).
    • Enhanced add-on creation, updates, and filtering to incorporate the instance type, ensuring more flexible and precise management.
    • Improved validation and API mapping ensure that only valid instance types are processed during add-on operations.

@tothandras tothandras added the release-note/feature Release note: Exciting New Features label Apr 5, 2025
@coderabbitai
Copy link
Contributor

coderabbitai bot commented Apr 5, 2025

📝 Walkthrough

Walkthrough

The changes integrate a new field, InstanceType, into the addon domain. The update spans database schema modifications, business logic, data mutation operations, and API mappings. The field is introduced as an enum type with allowed values ("single", "multiple") and a default value of "single". Adjustments include adding constants, validators, setters/getters, and predicate functions, along with corresponding migration scripts to add or remove the column from the database.

Changes

File(s) Change Summary
openmeter/ent/db/addon.go, openmeter/ent/db/addon/addon.go, openmeter/ent/db/addon/where.go Added InstanceType to the Addon struct, introduced related constants, validator, and predicate functions (EQ, NEQ, In, NotIn) for filtering on the new field.
openmeter/ent/db/addon_create.go, openmeter/ent/db/addon_update.go, openmeter/ent/db/mutation.go Introduced setter/getter methods (including nillable variants) and updated defaulting/validation logic for handling InstanceType in create, upsert, update, and mutation operations.
openmeter/ent/db/migrate/schema.go, tools/migrate/migrations/.../20250405193107_addon-instance-type.{up,down}.sql Updated the database schema to add the instance_type enum column (with default "single" and allowed values "single" and "multiple") and adjusted index column references; provided SQL migration scripts for adding and dropping the column.
openmeter/ent/db/runtime.go, openmeter/ent/schema/addon.go Modified field descriptor assignment in the runtime and updated the addon schema to include the new instance_type field.
openmeter/productcatalog/addon.go, openmeter/productcatalog/addon/adapter/addon.go, openmeter/productcatalog/addon/httpdriver/mapping.go, openmeter/productcatalog/addon/service.go Extended addon metadata and API mapping to incorporate InstanceType; defined the new type and constants, updated validation and equality checks, and added handling in adapter and service methods for creating/updating addons.

Warning

There were issues while running some tools. Please review the errors and either fix the tool's configuration or disable the tool if it's a critical failure.

🔧 golangci-lint (1.64.8)

Error: you are using a configuration file for golangci-lint v2 with golangci-lint v1: please use golangci-lint v2
Failed executing command with error: you are using a configuration file for golangci-lint v2 with golangci-lint v1: please use golangci-lint v2

🔧 SQLFluff (3.3.0)
tools/migrate/migrations/20250405193107_addon-instance-type.up.sql

User Error: No dialect was specified. You must configure a dialect or specify one on the command line using --dialect after the command. Available dialects:
ansi, athena, bigquery, clickhouse, databricks, db2, duckdb, exasol, greenplum, hive, impala, mariadb, materialize, mysql, oracle, postgres, redshift, snowflake, soql, sparksql, sqlite, starrocks, teradata, trino, tsql, vertica

tools/migrate/migrations/20250405193107_addon-instance-type.down.sql

User Error: No dialect was specified. You must configure a dialect or specify one on the command line using --dialect after the command. Available dialects:
ansi, athena, bigquery, clickhouse, databricks, db2, duckdb, exasol, greenplum, hive, impala, mariadb, materialize, mysql, oracle, postgres, redshift, snowflake, soql, sparksql, sqlite, starrocks, teradata, trino, tsql, vertica


📜 Recent review details

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 86c8510 and c645523.

⛔ Files ignored due to path filters (1)
  • tools/migrate/migrations/atlas.sum is excluded by !**/*.sum
📒 Files selected for processing (18)
  • openmeter/ent/db/addon.go (5 hunks)
  • openmeter/ent/db/addon/addon.go (5 hunks)
  • openmeter/ent/db/addon/where.go (2 hunks)
  • openmeter/ent/db/addon_create.go (8 hunks)
  • openmeter/ent/db/addon_update.go (7 hunks)
  • openmeter/ent/db/migrate/schema.go (2 hunks)
  • openmeter/ent/db/mutation.go (8 hunks)
  • openmeter/ent/db/runtime.go (1 hunks)
  • openmeter/ent/schema/addon.go (1 hunks)
  • openmeter/productcatalog/addon.go (4 hunks)
  • openmeter/productcatalog/addon/adapter/adapter_test.go (1 hunks)
  • openmeter/productcatalog/addon/adapter/addon.go (2 hunks)
  • openmeter/productcatalog/addon/adapter/mapping.go (1 hunks)
  • openmeter/productcatalog/addon/httpdriver/mapping.go (3 hunks)
  • openmeter/productcatalog/addon/service.go (3 hunks)
  • openmeter/productcatalog/addon/service/service_test.go (1 hunks)
  • tools/migrate/migrations/20250405193107_addon-instance-type.down.sql (1 hunks)
  • tools/migrate/migrations/20250405193107_addon-instance-type.up.sql (1 hunks)
🚧 Files skipped from review as they are similar to previous changes (15)
  • tools/migrate/migrations/20250405193107_addon-instance-type.down.sql
  • tools/migrate/migrations/20250405193107_addon-instance-type.up.sql
  • openmeter/productcatalog/addon/adapter/adapter_test.go
  • openmeter/ent/schema/addon.go
  • openmeter/productcatalog/addon/service/service_test.go
  • openmeter/productcatalog/addon/adapter/mapping.go
  • openmeter/ent/db/addon.go
  • openmeter/ent/db/runtime.go
  • openmeter/productcatalog/addon.go
  • openmeter/productcatalog/addon/httpdriver/mapping.go
  • openmeter/ent/db/addon_update.go
  • openmeter/ent/db/migrate/schema.go
  • openmeter/productcatalog/addon/adapter/addon.go
  • openmeter/productcatalog/addon/service.go
  • openmeter/ent/db/mutation.go
🧰 Additional context used
🧬 Code Definitions (3)
openmeter/ent/db/addon/addon.go (3)
openmeter/productcatalog/addon.go (1)
  • AddonInstanceType (202-202)
openmeter/ent/db/addonratecard/addonratecard.go (1)
  • OrderOption (143-143)
openmeter/ent/db/feature/feature.go (1)
  • OrderOption (111-111)
openmeter/ent/db/addon/where.go (5)
openmeter/productcatalog/addon.go (2)
  • AddonInstanceType (202-202)
  • Addon (160-165)
openmeter/ent/db/addon.go (2)
  • Addon (18-54)
  • Addon (75-94)
openmeter/ent/schema/addon.go (5)
  • Addon (17-19)
  • Addon (21-25)
  • Addon (27-52)
  • Addon (54-61)
  • Addon (63-78)
openmeter/ent/db/predicate/predicate.go (1)
  • Addon (10-10)
openmeter/ent/db/addon/addon.go (1)
  • FieldInstanceType (41-41)
openmeter/ent/db/addon_create.go (3)
openmeter/productcatalog/addon.go (1)
  • AddonInstanceType (202-202)
openmeter/ent/db/addon/addon.go (3)
  • DefaultInstanceType (115-115)
  • InstanceTypeValidator (118-125)
  • FieldInstanceType (41-41)
openmeter/ent/db/ent.go (1)
  • ValidationError (245-248)
⏰ Context from checks skipped due to timeout of 90000ms (9)
  • GitHub Check: Test
  • GitHub Check: Quickstart
  • GitHub Check: Lint
  • GitHub Check: E2E
  • GitHub Check: Developer environment
  • GitHub Check: CI
  • GitHub Check: Commit hooks
  • GitHub Check: Build
  • GitHub Check: Analyze (go)
🔇 Additional comments (22)
openmeter/ent/db/addon/addon.go (5)

6-6: Imports look appropriate.
No issues with adding "fmt" and productcatalog imports.

Also applies to: 12-12


40-41: New field constant definition.
Defining FieldInstanceType aligns well with existing pattern for field naming.


74-74: Added new column to Columns array.
Including FieldInstanceType here ensures queries and validations reference the new field correctly.


115-126: Default and validator for instance_type.
DefaultInstanceType is sensible to default to "single".
InstanceTypeValidator neatly constrains values to "single" or "multiple".


180-183: Ordering by the new field.
ByInstanceType is consistent with other ordering functions.

openmeter/ent/db/addon/where.go (5)

11-11: Added import for productcatalog.
No concerns. It's needed for the newly introduced predicates.


639-643: Equality predicate for instance_type.
Implementation follows existing patterns and is straightforward.


645-649: Non-equality predicate for instance_type.
Similarly consistent with other field predicates.


651-658: In predicate for instance_type.
Creating a slice of any for input values is correct for entgo’s predicate usage.


660-667: NotIn predicate for instance_type.
No issues; complements the In predicate and is implemented consistently.

openmeter/ent/db/addon_create.go (12)

17-17: Added import for productcatalog.
Needed for the new instance_type field. No concerns.


128-133: SetInstanceType method.
• Straightforward setter for the addon’s instance_type.
• Follows ent’s builder pattern.


134-140: SetNillableInstanceType method.
Allows setting instance_type only if a value is provided, which is useful for optional form inputs.


252-255: Applying default for instance_type.
Automatically sets the default if not specified. Good approach for ensuring a valid initial value.


305-312: Validation check for instance_type.
Ensures the field is present and valid. Consistent with the ent schema approach for required fields.


392-395: Adding instance_type to createSpec.
Makes instance_type persist in database creation calls; looks correct.


576-580: SetInstanceType in AddonUpsert.
No issues. Mirrors the pattern from other fields.


582-586: UpdateInstanceType in AddonUpsert.
Ties into the upsert flow, enabling instance_type to be updated on conflict.


814-819: SetInstanceType in AddonUpsertOne.
Same upsert setter approach for single-entity upsert.


821-826: UpdateInstanceType in AddonUpsertOne.
Allows instance_type to be replaced with the originally created value during conflicts.


1233-1238: SetInstanceType in AddonUpsertBulk.
Extends the same logic to bulk upsert.


1240-1245: UpdateInstanceType in AddonUpsertBulk.
Completes the upsert handling for instance_type in bulk operations.

✨ Finishing Touches
  • 📝 Generate Docstrings

🪧 Tips

Chat

There are 3 ways to chat with CodeRabbit:

  • Review comments: Directly reply to a review comment made by CodeRabbit. Example:
    • I pushed a fix in commit <commit_id>, please review it.
    • Generate unit testing code for this file.
    • Open a follow-up GitHub issue for this discussion.
  • Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
    • @coderabbitai generate unit testing code for this file.
    • @coderabbitai modularize this function.
  • PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
    • @coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
    • @coderabbitai read src/utils.ts and generate unit testing code.
    • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.
    • @coderabbitai help me debug CodeRabbit configuration file.

Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments.

CodeRabbit Commands (Invoked using PR comments)

  • @coderabbitai pause to pause the reviews on a PR.
  • @coderabbitai resume to resume the paused reviews.
  • @coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
  • @coderabbitai full review to do a full review from scratch and review all the files again.
  • @coderabbitai summary to regenerate the summary of the PR.
  • @coderabbitai generate docstrings to generate docstrings for this PR.
  • @coderabbitai resolve resolve all the CodeRabbit review comments.
  • @coderabbitai plan to trigger planning for file edits and PR creation.
  • @coderabbitai configuration to show the current CodeRabbit configuration for the repository.
  • @coderabbitai help to get help.

Other keywords and placeholders

  • Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
  • Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
  • Add @coderabbitai anywhere in the PR title to generate the title automatically.

CodeRabbit Configuration File (.coderabbit.yaml)

  • You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
  • Please see the configuration documentation for more information.
  • If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json

Documentation and Community

  • Visit our Documentation for detailed information on how to use CodeRabbit.
  • Join our Discord Community to get help, request features, and share feedback.
  • Follow us on X/Twitter for updates and announcements.

@tothandras tothandras marked this pull request as ready for review April 5, 2025 19:23
@tothandras tothandras requested a review from a team as a code owner April 5, 2025 19:23
Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

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

Actionable comments posted: 0

🧹 Nitpick comments (1)
openmeter/ent/schema/addon.go (1)

35-36: LGTM! The instance_type field is properly defined.

The new field is correctly added to the Addon schema as an Enum type with appropriate Go type mapping.

However, since this is an enum field, consider adding validation to ensure only valid instance types are accepted.

You may want to enhance this implementation by adding validation options:

 field.Enum("instance_type").
-    GoType(productcatalog.AddonInstanceType(""))
+    GoType(productcatalog.AddonInstanceType("")).
+    Comment("The instance type of the addon").
+    Validators(validation.NotEmpty)
📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between cd71c45 and 51a733e.

⛔ Files ignored due to path filters (1)
  • tools/migrate/migrations/atlas.sum is excluded by !**/*.sum
📒 Files selected for processing (15)
  • openmeter/ent/db/addon.go (5 hunks)
  • openmeter/ent/db/addon/addon.go (5 hunks)
  • openmeter/ent/db/addon/where.go (2 hunks)
  • openmeter/ent/db/addon_create.go (7 hunks)
  • openmeter/ent/db/addon_update.go (7 hunks)
  • openmeter/ent/db/migrate/schema.go (2 hunks)
  • openmeter/ent/db/mutation.go (8 hunks)
  • openmeter/ent/db/runtime.go (1 hunks)
  • openmeter/ent/schema/addon.go (1 hunks)
  • openmeter/productcatalog/addon.go (4 hunks)
  • openmeter/productcatalog/addon/adapter/addon.go (2 hunks)
  • openmeter/productcatalog/addon/httpdriver/mapping.go (3 hunks)
  • openmeter/productcatalog/addon/service.go (3 hunks)
  • tools/migrate/migrations/20250405192121_addon-instance-type.down.sql (1 hunks)
  • tools/migrate/migrations/20250405192121_addon-instance-type.up.sql (1 hunks)
🧰 Additional context used
🧬 Code Definitions (9)
openmeter/ent/schema/addon.go (1)
openmeter/productcatalog/addon.go (1)
  • AddonInstanceType (202-202)
openmeter/ent/db/addon.go (2)
openmeter/productcatalog/addon.go (1)
  • AddonInstanceType (202-202)
openmeter/ent/db/addon/addon.go (1)
  • FieldInstanceType (41-41)
openmeter/ent/db/addon/addon.go (3)
openmeter/productcatalog/addon.go (1)
  • AddonInstanceType (202-202)
openmeter/ent/db/addonratecard/addonratecard.go (1)
  • OrderOption (143-143)
openmeter/ent/db/feature/feature.go (1)
  • OrderOption (111-111)
openmeter/ent/db/migrate/schema.go (5)
openmeter/ent/db/feature/where.go (1)
  • Name (89-91)
openmeter/ent/db/customer/customer.go (1)
  • Columns (101-120)
openmeter/ent/db/planphase/planphase.go (1)
  • Columns (62-75)
openmeter/ent/db/addon/addon.go (1)
  • Columns (62-78)
openmeter/ent/db/plan/plan.go (1)
  • Columns (66-81)
openmeter/ent/db/addon_update.go (3)
openmeter/productcatalog/addon.go (1)
  • AddonInstanceType (202-202)
openmeter/ent/db/addon/addon.go (1)
  • InstanceTypeValidator (116-123)
openmeter/ent/db/ent.go (1)
  • ValidationError (245-248)
openmeter/productcatalog/addon/service.go (1)
openmeter/productcatalog/addon.go (1)
  • AddonInstanceType (202-202)
openmeter/ent/db/mutation.go (5)
api/api.gen.go (1)
  • AddonInstanceType (841-841)
api/client/go/client.gen.go (1)
  • AddonInstanceType (774-774)
api/client/javascript/src/client/schemas.ts (1)
  • AddonInstanceType (8822-8822)
openmeter/productcatalog/addon.go (1)
  • AddonInstanceType (202-202)
openmeter/ent/db/addon/addon.go (1)
  • FieldInstanceType (41-41)
openmeter/ent/db/addon_create.go (3)
openmeter/productcatalog/addon.go (1)
  • AddonInstanceType (202-202)
openmeter/ent/db/ent.go (1)
  • ValidationError (245-248)
openmeter/ent/db/addon/addon.go (2)
  • InstanceTypeValidator (116-123)
  • FieldInstanceType (41-41)
openmeter/ent/db/addon/where.go (6)
openmeter/productcatalog/addon.go (2)
  • AddonInstanceType (202-202)
  • Addon (160-165)
openmeter/ent/db/addon.go (2)
  • Addon (18-54)
  • Addon (75-94)
openmeter/ent/schema/addon.go (5)
  • Addon (17-19)
  • Addon (21-25)
  • Addon (27-51)
  • Addon (53-60)
  • Addon (62-77)
openmeter/ent/db/predicate/predicate.go (1)
  • Addon (10-10)
openmeter/productcatalog/addon/addon.go (1)
  • Addon (13-21)
openmeter/ent/db/addon/addon.go (1)
  • FieldInstanceType (41-41)
⏰ Context from checks skipped due to timeout of 90000ms (9)
  • GitHub Check: Test
  • GitHub Check: Quickstart
  • GitHub Check: Lint
  • GitHub Check: E2E
  • GitHub Check: Developer environment
  • GitHub Check: CI
  • GitHub Check: Commit hooks
  • GitHub Check: Build
  • GitHub Check: Analyze (go)
🔇 Additional comments (52)
tools/migrate/migrations/20250405192121_addon-instance-type.up.sql (1)

1-2:

Details

❓ Verification inconclusive

Verify error handling for existing data during migration.

The migration adds a NOT NULL column without providing a default value. If the table already contains data, this migration will fail unless the column is initially populated.

Consider running the following script to check if the addons table has existing records:

If there are existing records, consider one of these approaches:

  1. Add a DEFAULT clause to the column definition
  2. Perform a two-step migration (add nullable column, update data, then add NOT NULL constraint)

🏁 Script executed:

#!/bin/bash
# Check if the addons table has existing records that would require a default value
psql -c "SELECT COUNT(*) FROM addons;" || echo "Table may not exist yet"

Length of output: 192


Attention: Review Migration for Handling Existing Data in Addons Table

The migration in tools/migrate/migrations/20250405192121_addon-instance-type.up.sql currently adds a NOT NULL column without a default value. This can cause the migration to fail if the addons table contains existing data. Our verification script did not conclusively check for existing records because the psql command was not available, resulting in:

  • Output: "Table may not exist yet"

Considerations:

  • Ensure that the migration is executed in an environment where psql is available and the addons table can be reliably queried.
  • If the table contains records:
    • Either add a DEFAULT clause to the column definition.
    • Or use a two-step migration: first add the column as nullable, update/populate the column data, and then constrain it as NOT NULL.
tools/migrate/migrations/20250405192121_addon-instance-type.down.sql (1)

1-2: LGTM! The down migration properly reverses the changes.

The migration correctly removes the "instance_type" column from the "addons" table.

openmeter/ent/db/runtime.go (1)

89-89: LGTM! Updated index accounts for the new field.

This change correctly updates the index from addonFields[4] to addonFields[5] to account for the newly added instance_type field, which shifts the position of the annotations field descriptor.

openmeter/ent/db/addon.go (5)

14-14: Import dependency added appropriately.

The import for productcatalog is correctly added to support the new AddonInstanceType field.


42-43: New InstanceType field looks good.

The field is properly defined with the correct type and JSON tag, following the established pattern for other fields in the struct.


83-83: Field correctly added to scanValues method.

The FieldInstanceType is properly added to the list of fields that create a sql.NullString, which is appropriate since AddonInstanceType is a string type.


174-179: Proper handling of the new field in assignValues.

The case implementation follows the established pattern by checking the type and setting the value with appropriate error handling.


275-277: String representation update is correct.

The String method is properly updated to include the new field in the string representation.

openmeter/ent/db/migrate/schema.go (2)

25-25: New enum column definition is correct.

The instance_type column is properly defined as an enum type with valid values "single" and "multiple".


67-67: Index reference properly updated.

The column reference in the addon_annotations index is correctly updated to reflect the insertion of the new column.

openmeter/ent/db/addon/addon.go (5)

6-6: Imports added appropriately.

The necessary imports for fmt and productcatalog are correctly added to support the new functionality.

Also applies to: 12-12


40-41: Field constant definition looks good.

The constant for the instance_type field is properly defined and follows the naming convention.


74-74: Field added to Columns array.

The field is correctly added to the Columns array, which is necessary for it to be recognized as a valid column.


115-123: Validator function implementation is correct.

The validator function appropriately restricts values to "single" and "multiple" with proper error messaging.


178-181: Ordering function follows established pattern.

The ByInstanceType function correctly implements ordering by the instance_type field, following the same pattern as other ordering functions.

openmeter/productcatalog/addon/service.go (3)

140-142: Field added to UpdateAddonInput struct correctly.

The InstanceType field is properly defined with the right type and appropriate JSON tag.


172-174: Equal method comparison is implemented correctly.

The comparison logic for the new field follows the established pattern, checking only if the field is not nil.


200-204: Validation logic is properly implemented.

The validation logic for the InstanceType field correctly handles nil values and uses the field's Validate method.

openmeter/productcatalog/addon/httpdriver/mapping.go (3)

31-31: LGTM: Added proper field mapping for InstanceType

The field is properly mapped from the domain type to the API type using a consistent pattern with the existing code.


67-71: LGTM: InstanceType field added to AddonMeta

The InstanceType field is correctly added to the AddonMeta structure in the CreateAddonRequest, following the same pattern as other fields.


96-99: LGTM: InstanceType field included in UpdateAddonRequest

The InstanceType field is properly included in the UpdateAddonRequest structure, correctly wrapped with lo.ToPtr() for nullable handling.

openmeter/productcatalog/addon.go (4)

55-57: LGTM: InstanceType field added to AddonMeta struct

The field is properly added with appropriate JSON tag and documentation.


84-86: LGTM: Validation for InstanceType added

The Validate method is correctly updated to include validation for the InstanceType field, following the same error handling pattern as other fields.


112-114: LGTM: Equal method updated for InstanceType

The Equal method is appropriately updated to compare the InstanceType field between two AddonMeta instances.


202-224: LGTM: AddonInstanceType type and methods implemented

The implementation includes:

  1. A clear type definition as a string
  2. Well-named constants with descriptive values
  3. A proper Validate method that checks against valid values
  4. A Values method that returns all valid string representations

This follows best practices for type-safe enums in Go.

openmeter/ent/db/addon_update.go (6)

126-138: LGTM: SetInstanceType methods added to AddonUpdate

Both the direct setter and nullable setter methods are implemented correctly, following the same pattern as other fields in the struct.


276-280: LGTM: Validation check added for InstanceType

The check method is properly updated to validate the InstanceType field using the InstanceTypeValidator.


326-328: LGTM: SQL field setting for InstanceType added

The sqlSave method correctly sets the InstanceType field in the SQL update specification when it's defined in the mutation.


509-521: LGTM: SetInstanceType methods added to AddonUpdateOne

Both direct and nullable setter methods are implemented correctly, consistent with the AddonUpdate struct implementation.


672-676: LGTM: Validation check added for AddonUpdateOne

The check method in AddonUpdateOne is properly updated to validate the InstanceType field.


739-741: LGTM: SQL field setting for AddonUpdateOne

The sqlSave method for AddonUpdateOne correctly sets the InstanceType field in the SQL update specification.

openmeter/ent/db/addon/where.go (4)

639-643: LGTM: InstanceTypeEQ predicate added

The equality predicate is correctly implemented for filtering by InstanceType.


645-649: LGTM: InstanceTypeNEQ predicate added

The non-equality predicate is correctly implemented for filtering by InstanceType.


651-658: LGTM: InstanceTypeIn predicate added

The inclusion predicate is correctly implemented, with proper type conversion from the domain-specific type to the required internal representation.


660-667: LGTM: InstanceTypeNotIn predicate added

The non-inclusion predicate is correctly implemented, following the same pattern as InstanceTypeIn.

openmeter/productcatalog/addon/adapter/addon.go (2)

177-177: The instance type field is properly set during addon creation.

The addition of SetInstanceType is correctly implemented in the CreateAddon method, ensuring that when creating a new addon, the instance type is properly initialized.


438-440: LGTM: Instance type handling added to UpdateAddon

The implementation for updating the instance type follows the same pattern as other nullable fields in the method. The nil check ensures that the instance type is only updated when explicitly provided in the input parameters.

openmeter/ent/db/mutation.go (8)

125-128: Addition of instance_type field follows established pattern

The addition of the instance_type field to the AddonMutation struct with the pointer type *productcatalog.AddonInstanceType is consistent with the existing field pattern in this struct.


664-698: LGTM: Accessor methods for instance_type are well-implemented

All the accessor methods follow the established patterns in the codebase:

  • SetInstanceType sets the value
  • InstanceType returns the current value and existence flag
  • OldInstanceType retrieves previous value with proper error handling
  • ResetInstanceType resets the field

The error handling in OldInstanceType thoroughly validates operation type and ID requirements before accessing the database.


935-935: Capacity increased to accommodate new field

Appropriate increase of the fields slice capacity from 13 to 14 to optimize memory allocation for the new field.


966-968: Field registration follows established pattern

The conditional check and field registration for instance_type in the Fields() method follows the consistent pattern used for other fields.


1006-1007: Field accessor properly integrated

The new case for addon.FieldInstanceType in the Field() method correctly returns the result of m.InstanceType().


1043-1044: OldField accessor properly integrated

The new case for addon.FieldInstanceType in the OldField() method correctly returns the result of m.OldInstanceType(ctx).


1130-1136: SetField implementation with proper type checking

The implementation for handling instance_type in the SetField() method includes appropriate type assertion and error handling, following the pattern used for other fields.


1291-1293: ResetField implementation is correct

The implementation for resetting instance_type in the ResetField() method correctly calls m.ResetInstanceType().

openmeter/ent/db/addon_create.go (7)

17-17: Import added correctly for required type.

The import for productcatalog is necessary to use the AddonInstanceType defined in that package.


128-132: Setter method is properly implemented.

This method follows the consistent pattern used throughout the codebase for field setters - taking a parameter of the correct type, delegating to the mutation object, and returning *AddonCreate for method chaining.


293-300: Validation logic added correctly.

The validation properly:

  1. Checks that the required field is present
  2. Uses the InstanceTypeValidator function to ensure valid values ("single" or "multiple")
  3. Returns appropriate validation errors with descriptive messages

This maintains consistency with other field validations in the codebase.


380-383: Field creation correctly implemented.

The code properly:

  1. Checks if the instance_type value is present in the mutation
  2. Sets it in the specification with the correct field type (TypeEnum)
  3. Sets the value on the node object

This follows the pattern used for other fields in the file.


564-574: Upsert methods properly implemented.

These methods provide the ability to:

  1. Set a specific instance_type value during upsert
  2. Update instance_type to the value provided during creation

This maintains consistency with other field handling in the upsert operations.


802-814: UpsertOne methods properly implemented.

The methods correctly delegate to the AddonUpsert methods through the Update function, maintaining the pattern used for other fields in the AddonUpsertOne structure.


1221-1233: Bulk upsert methods properly implemented.

The bulk upsert methods correctly delegate to the AddonUpsert methods through the Update function, maintaining the pattern used for other fields in the AddonUpsertBulk structure.

@tothandras tothandras force-pushed the feat/addon-type branch 4 times, most recently from de5b011 to 86c8510 Compare April 5, 2025 20:08
@tothandras tothandras merged commit 44cf60f into main Apr 5, 2025
27 checks passed
@tothandras tothandras deleted the feat/addon-type branch April 5, 2025 20:41
@coderabbitai coderabbitai bot mentioned this pull request Apr 8, 2025
@coderabbitai coderabbitai bot mentioned this pull request Apr 16, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

release-note/feature Release note: Exciting New Features

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants