refactor: split lines DDL #2964
Conversation
📝 WalkthroughWalkthroughThis change introduces a new entity, Changes
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 ✨ Finishing Touches
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. 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)
Other keywords and placeholders
CodeRabbit Configuration File (
|
turip
force-pushed
the
refactor/split-lines-v2-ddl
branch
from
a83f392 to
9871466
Compare
turip
added
release-note/ignore
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (1)
openmeter/ent/schema/billing.go (1)
402-409: Consider documenting the temporary nature of this fieldThe comment indicates this field is "only valid for ubp lines" and that the table will "eventually become the 'ubp' table". This suggests a planned refactoring that should be tracked properly.
Would you like me to create an issue to track this technical debt and the planned refactoring of the billing invoice lines table?
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
tools/migrate/migrations/atlas.sumis excluded by!**/*.sum
📒 Files selected for processing (45)
openmeter/ent/db/billinginvoiceline.go(20 hunks)openmeter/ent/db/billinginvoiceline/billinginvoiceline.go(9 hunks)openmeter/ent/db/billinginvoiceline/where.go(5 hunks)openmeter/ent/db/billinginvoiceline_create.go(15 hunks)openmeter/ent/db/billinginvoiceline_query.go(9 hunks)openmeter/ent/db/billinginvoiceline_update.go(15 hunks)openmeter/ent/db/billinginvoicesplitlinegroup.go(1 hunks)openmeter/ent/db/billinginvoicesplitlinegroup/billinginvoicesplitlinegroup.go(1 hunks)openmeter/ent/db/billinginvoicesplitlinegroup/where.go(1 hunks)openmeter/ent/db/billinginvoicesplitlinegroup_create.go(1 hunks)openmeter/ent/db/billinginvoicesplitlinegroup_delete.go(1 hunks)openmeter/ent/db/billinginvoicesplitlinegroup_query.go(1 hunks)openmeter/ent/db/billinginvoicesplitlinegroup_update.go(1 hunks)openmeter/ent/db/client.go(14 hunks)openmeter/ent/db/ent.go(2 hunks)openmeter/ent/db/expose.go(1 hunks)openmeter/ent/db/hook/hook.go(1 hunks)openmeter/ent/db/migrate/schema.go(7 hunks)openmeter/ent/db/paginate.go(1 hunks)openmeter/ent/db/predicate/predicate.go(1 hunks)openmeter/ent/db/runtime.go(4 hunks)openmeter/ent/db/setorclear.go(3 hunks)openmeter/ent/db/subscription.go(3 hunks)openmeter/ent/db/subscription/subscription.go(4 hunks)openmeter/ent/db/subscription/where.go(1 hunks)openmeter/ent/db/subscription_create.go(3 hunks)openmeter/ent/db/subscription_query.go(8 hunks)openmeter/ent/db/subscription_update.go(7 hunks)openmeter/ent/db/subscriptionitem.go(3 hunks)openmeter/ent/db/subscriptionitem/subscriptionitem.go(4 hunks)openmeter/ent/db/subscriptionitem/where.go(1 hunks)openmeter/ent/db/subscriptionitem_create.go(3 hunks)openmeter/ent/db/subscriptionitem_query.go(8 hunks)openmeter/ent/db/subscriptionitem_update.go(7 hunks)openmeter/ent/db/subscriptionphase.go(3 hunks)openmeter/ent/db/subscriptionphase/subscriptionphase.go(4 hunks)openmeter/ent/db/subscriptionphase/where.go(1 hunks)openmeter/ent/db/subscriptionphase_create.go(3 hunks)openmeter/ent/db/subscriptionphase_query.go(8 hunks)openmeter/ent/db/subscriptionphase_update.go(7 hunks)openmeter/ent/db/tx.go(2 hunks)openmeter/ent/schema/billing.go(4 hunks)openmeter/ent/schema/subscription.go(3 hunks)tools/migrate/migrations/20250609104934_billing-split-line-group.down.sql(1 hunks)tools/migrate/migrations/20250609104934_billing-split-line-group.up.sql(1 hunks)
🧰 Additional context used
🧬 Code Graph Analysis (19)
openmeter/ent/db/ent.go (1)
openmeter/ent/db/billinginvoicesplitlinegroup/billinginvoicesplitlinegroup.go (2)
Table(65-65)ValidColumn(120-127)
openmeter/ent/db/subscriptionphase/where.go (6)
openmeter/ent/db/subscription/where.go (2)
HasBillingSplitLineGroups(892-900)HasBillingSplitLineGroupsWith(903-912)openmeter/ent/db/subscriptionitem/where.go (2)
HasBillingSplitLineGroups(1289-1297)HasBillingSplitLineGroupsWith(1300-1309)openmeter/ent/db/subscriptionphase.go (2)
SubscriptionPhase(18-48)SubscriptionPhase(104-121)openmeter/ent/schema/subscription.go (5)
SubscriptionPhase(66-68)SubscriptionPhase(70-77)SubscriptionPhase(79-88)SubscriptionPhase(90-96)SubscriptionPhase(98-107)openmeter/ent/db/billinginvoicesplitlinegroup/billinginvoicesplitlinegroup.go (2)
Table(65-65)FieldID(19-19)openmeter/ent/db/subscriptionphase/subscriptionphase.go (4)
Table(48-48)FieldID(16-16)BillingSplitLineGroupsTable(71-71)BillingSplitLineGroupsColumn(76-76)
openmeter/ent/db/predicate/predicate.go (2)
openmeter/ent/db/billinginvoicesplitlinegroup.go (2)
BillingInvoiceSplitLineGroup(23-67)BillingInvoiceSplitLineGroup(127-146)openmeter/ent/schema/billing.go (5)
BillingInvoiceSplitLineGroup(582-584)BillingInvoiceSplitLineGroup(586-591)BillingInvoiceSplitLineGroup(593-632)BillingInvoiceSplitLineGroup(634-641)BillingInvoiceSplitLineGroup(643-659)
openmeter/ent/db/tx.go (4)
openmeter/ent/db/billinginvoicesplitlinegroup.go (2)
BillingInvoiceSplitLineGroup(23-67)BillingInvoiceSplitLineGroup(127-146)openmeter/ent/schema/billing.go (5)
BillingInvoiceSplitLineGroup(582-584)BillingInvoiceSplitLineGroup(586-591)BillingInvoiceSplitLineGroup(593-632)BillingInvoiceSplitLineGroup(634-641)BillingInvoiceSplitLineGroup(643-659)openmeter/ent/db/predicate/predicate.go (1)
BillingInvoiceSplitLineGroup(113-113)openmeter/ent/db/client.go (2)
BillingInvoiceSplitLineGroupClient(3435-3437)NewBillingInvoiceSplitLineGroupClient(3440-3442)
openmeter/ent/db/expose.go (4)
openmeter/ent/db/billinginvoicesplitlinegroup.go (2)
BillingInvoiceSplitLineGroup(23-67)BillingInvoiceSplitLineGroup(127-146)openmeter/ent/schema/billing.go (5)
BillingInvoiceSplitLineGroup(582-584)BillingInvoiceSplitLineGroup(586-591)BillingInvoiceSplitLineGroup(593-632)BillingInvoiceSplitLineGroup(634-641)BillingInvoiceSplitLineGroup(643-659)openmeter/ent/db/predicate/predicate.go (1)
BillingInvoiceSplitLineGroup(113-113)openmeter/ent/db/client.go (1)
NewBillingInvoiceSplitLineGroupClient(3440-3442)
openmeter/ent/db/billinginvoicesplitlinegroup_delete.go (5)
openmeter/ent/db/ent.go (3)
IsConstraintError(367-373)ConstraintError(351-354)NotFoundError(284-286)openmeter/ent/db/mutation.go (1)
BillingInvoiceSplitLineGroupMutation(21698-21731)openmeter/ent/db/billinginvoicesplitlinegroup.go (2)
BillingInvoiceSplitLineGroup(23-67)BillingInvoiceSplitLineGroup(127-146)openmeter/ent/db/predicate/predicate.go (1)
BillingInvoiceSplitLineGroup(113-113)openmeter/ent/db/billinginvoicesplitlinegroup/billinginvoicesplitlinegroup.go (3)
Table(65-65)FieldID(19-19)Label(17-17)
openmeter/ent/db/hook/hook.go (2)
openmeter/ent/db/mutation.go (1)
BillingInvoiceSplitLineGroupMutation(21698-21731)openmeter/ent/db/ent.go (2)
Value(67-67)Mutation(78-78)
openmeter/ent/db/subscription/subscription.go (3)
openmeter/ent/db/subscriptionitem/subscriptionitem.go (8)
ByBillingSplitLineGroupsCount(309-313)OrderOption(168-168)ByBillingSplitLineGroups(316-320)Table(72-72)FieldID(18-18)BillingSplitLineGroupsInverseTable(98-98)BillingSplitLineGroupsTable(95-95)BillingSplitLineGroupsColumn(100-100)openmeter/ent/db/subscriptionphase/subscriptionphase.go (8)
ByBillingSplitLineGroupsCount(218-222)OrderOption(125-125)ByBillingSplitLineGroups(225-229)Table(48-48)FieldID(16-16)BillingSplitLineGroupsInverseTable(74-74)BillingSplitLineGroupsTable(71-71)BillingSplitLineGroupsColumn(76-76)openmeter/ent/db/billinginvoicesplitlinegroup/billinginvoicesplitlinegroup.go (3)
OrderOption(150-150)Table(65-65)FieldID(19-19)
openmeter/ent/db/subscriptionphase_create.go (4)
openmeter/ent/schema/billing.go (5)
BillingInvoiceSplitLineGroup(582-584)BillingInvoiceSplitLineGroup(586-591)BillingInvoiceSplitLineGroup(593-632)BillingInvoiceSplitLineGroup(634-641)BillingInvoiceSplitLineGroup(643-659)openmeter/ent/db/subscriptionphase/where.go (1)
ID(14-16)openmeter/ent/db/billinginvoicesplitlinegroup/billinginvoicesplitlinegroup.go (2)
Table(65-65)FieldID(19-19)openmeter/ent/db/subscriptionphase/subscriptionphase.go (4)
Table(48-48)BillingSplitLineGroupsTable(71-71)BillingSplitLineGroupsColumn(76-76)FieldID(16-16)
openmeter/ent/schema/subscription.go (3)
openmeter/ent/db/billinginvoicesplitlinegroup.go (2)
BillingInvoiceSplitLineGroup(23-67)BillingInvoiceSplitLineGroup(127-146)openmeter/ent/schema/billing.go (5)
BillingInvoiceSplitLineGroup(582-584)BillingInvoiceSplitLineGroup(586-591)BillingInvoiceSplitLineGroup(593-632)BillingInvoiceSplitLineGroup(634-641)BillingInvoiceSplitLineGroup(643-659)openmeter/ent/db/predicate/predicate.go (1)
BillingInvoiceSplitLineGroup(113-113)
openmeter/ent/db/subscriptionphase/subscriptionphase.go (5)
openmeter/ent/db/subscription/subscription.go (8)
ByBillingSplitLineGroupsCount(263-267)OrderOption(153-153)ByBillingSplitLineGroups(270-274)Table(56-56)FieldID(16-16)BillingSplitLineGroupsInverseTable(89-89)BillingSplitLineGroupsTable(86-86)BillingSplitLineGroupsColumn(91-91)openmeter/ent/db/subscriptionitem/subscriptionitem.go (8)
ByBillingSplitLineGroupsCount(309-313)OrderOption(168-168)ByBillingSplitLineGroups(316-320)Table(72-72)FieldID(18-18)BillingSplitLineGroupsInverseTable(98-98)BillingSplitLineGroupsTable(95-95)BillingSplitLineGroupsColumn(100-100)openmeter/ent/db/billinginvoicesplitlinegroup/billinginvoicesplitlinegroup.go (3)
OrderOption(150-150)Table(65-65)FieldID(19-19)openmeter/ent/db/customer/customer.go (3)
OrderOption(150-150)Table(62-62)FieldID(16-16)openmeter/ent/db/billinginvoiceline/billinginvoiceline.go (3)
OrderOption(297-297)Table(109-109)FieldID(19-19)
openmeter/ent/db/subscriptionitem/subscriptionitem.go (4)
openmeter/ent/db/subscription/subscription.go (8)
ByBillingSplitLineGroupsCount(263-267)OrderOption(153-153)ByBillingSplitLineGroups(270-274)Table(56-56)FieldID(16-16)BillingSplitLineGroupsInverseTable(89-89)BillingSplitLineGroupsTable(86-86)BillingSplitLineGroupsColumn(91-91)openmeter/ent/db/subscriptionphase/subscriptionphase.go (8)
ByBillingSplitLineGroupsCount(218-222)OrderOption(125-125)ByBillingSplitLineGroups(225-229)Table(48-48)FieldID(16-16)BillingSplitLineGroupsInverseTable(74-74)BillingSplitLineGroupsTable(71-71)BillingSplitLineGroupsColumn(76-76)openmeter/ent/db/billinginvoicesplitlinegroup/billinginvoicesplitlinegroup.go (3)
OrderOption(150-150)Table(65-65)FieldID(19-19)openmeter/ent/db/billinginvoiceline/billinginvoiceline.go (3)
OrderOption(297-297)Table(109-109)FieldID(19-19)
openmeter/ent/db/subscription_update.go (3)
openmeter/ent/schema/billing.go (5)
BillingInvoiceSplitLineGroup(582-584)BillingInvoiceSplitLineGroup(586-591)BillingInvoiceSplitLineGroup(593-632)BillingInvoiceSplitLineGroup(634-641)BillingInvoiceSplitLineGroup(643-659)openmeter/ent/db/billinginvoicesplitlinegroup/billinginvoicesplitlinegroup.go (3)
Table(65-65)Columns(97-117)FieldID(19-19)openmeter/ent/db/subscription/subscription.go (5)
Table(56-56)BillingSplitLineGroupsTable(86-86)Columns(102-117)BillingSplitLineGroupsColumn(91-91)FieldID(16-16)
openmeter/ent/db/runtime.go (7)
openmeter/ent/db/billinginvoicesplitlinegroup/billinginvoicesplitlinegroup.go (6)
CurrencyValidator(139-139)DefaultCreatedAt(133-133)DefaultUpdatedAt(135-135)UpdateDefaultUpdatedAt(137-137)ValueScanner(143-146)DefaultID(141-141)openmeter/ent/db/billinginvoiceline/billinginvoiceline.go (6)
CurrencyValidator(257-257)DefaultCreatedAt(251-251)DefaultUpdatedAt(253-253)UpdateDefaultUpdatedAt(255-255)ValueScanner(261-263)DefaultID(259-259)openmeter/ent/db/billinginvoicesplitlinegroup.go (2)
BillingInvoiceSplitLineGroup(23-67)BillingInvoiceSplitLineGroup(127-146)openmeter/ent/schema/billing.go (5)
BillingInvoiceSplitLineGroup(582-584)BillingInvoiceSplitLineGroup(586-591)BillingInvoiceSplitLineGroup(593-632)BillingInvoiceSplitLineGroup(634-641)BillingInvoiceSplitLineGroup(643-659)openmeter/ent/db/billinginvoiceusagebasedlineconfig/billinginvoiceusagebasedlineconfig.go (2)
ValueScanner(64-66)DefaultID(62-62)openmeter/billing/discount.go (1)
Discounts(78-81)openmeter/productcatalog/price.go (1)
Price(84-91)
openmeter/ent/db/billinginvoiceline_query.go (6)
openmeter/ent/db/billinginvoicesplitlinegroup_query.go (1)
BillingInvoiceSplitLineGroupQuery(25-39)openmeter/ent/db/client.go (1)
BillingInvoiceSplitLineGroupClient(3435-3437)openmeter/ent/schema/billing.go (10)
BillingInvoiceLine(320-322)BillingInvoiceLine(324-330)BillingInvoiceLine(332-419)BillingInvoiceLine(421-431)BillingInvoiceLine(433-474)BillingInvoiceSplitLineGroup(582-584)BillingInvoiceSplitLineGroup(586-591)BillingInvoiceSplitLineGroup(593-632)BillingInvoiceSplitLineGroup(634-641)BillingInvoiceSplitLineGroup(643-659)openmeter/ent/db/billinginvoiceline.go (2)
BillingInvoiceLine(28-106)BillingInvoiceLine(253-278)openmeter/ent/db/billinginvoicesplitlinegroup.go (2)
BillingInvoiceSplitLineGroup(23-67)BillingInvoiceSplitLineGroup(127-146)openmeter/ent/db/billinginvoiceline/where.go (2)
SplitLineGroupID(198-200)ID(17-19)
openmeter/ent/db/migrate/schema.go (5)
openmeter/ent/db/billinginvoicesplitlinegroup/billinginvoicesplitlinegroup.go (3)
Columns(97-117)Table(65-65)BillingInvoiceLinesTable(67-67)openmeter/ent/db/subscription/subscription.go (2)
Columns(102-117)Table(56-56)openmeter/ent/db/subscriptionitem/subscriptionitem.go (2)
Columns(104-128)Table(72-72)openmeter/ent/db/subscriptionphase/subscriptionphase.go (2)
Columns(80-93)Table(48-48)openmeter/ent/db/billinginvoiceline/billinginvoiceline.go (2)
Columns(184-218)Table(109-109)
openmeter/ent/db/billinginvoiceline.go (5)
openmeter/ent/db/billinginvoiceline/where.go (4)
PeriodStart(102-104)PeriodEnd(107-109)Currency(112-115)SplitLineGroupID(198-200)pkg/currencyx/currency.go (1)
Code(12-12)openmeter/productcatalog/tax.go (1)
TaxConfig(36-39)openmeter/ent/db/billinginvoicesplitlinegroup.go (2)
BillingInvoiceSplitLineGroup(23-67)BillingInvoiceSplitLineGroup(127-146)openmeter/ent/db/ent.go (2)
NotFoundError(284-286)NotLoadedError(330-332)
openmeter/ent/db/subscriptionphase_query.go (4)
openmeter/ent/db/subscriptionphase.go (2)
SubscriptionPhase(18-48)SubscriptionPhase(104-121)openmeter/ent/db/billinginvoicesplitlinegroup_query.go (1)
BillingInvoiceSplitLineGroupQuery(25-39)openmeter/ent/db/billinginvoicesplitlinegroup.go (2)
BillingInvoiceSplitLineGroup(23-67)BillingInvoiceSplitLineGroup(127-146)openmeter/ent/schema/billing.go (5)
BillingInvoiceSplitLineGroup(582-584)BillingInvoiceSplitLineGroup(586-591)BillingInvoiceSplitLineGroup(593-632)BillingInvoiceSplitLineGroup(634-641)BillingInvoiceSplitLineGroup(643-659)
openmeter/ent/db/subscriptionitem_query.go (8)
openmeter/ent/db/billinginvoicesplitlinegroup/billinginvoicesplitlinegroup.go (2)
OrderOption(150-150)FieldID(19-19)openmeter/ent/db/subscriptionitem.go (2)
SubscriptionItem(21-73)SubscriptionItem(131-158)openmeter/ent/schema/subscription.go (5)
SubscriptionItem(109-111)SubscriptionItem(113-120)SubscriptionItem(122-185)SubscriptionItem(187-192)SubscriptionItem(194-203)openmeter/ent/db/predicate/predicate.go (2)
SubscriptionItem(262-262)BillingInvoiceSplitLineGroup(113-113)openmeter/ent/db/billinginvoicesplitlinegroup_query.go (1)
BillingInvoiceSplitLineGroupQuery(25-39)openmeter/ent/db/client.go (1)
BillingInvoiceSplitLineGroupClient(3435-3437)openmeter/ent/schema/billing.go (5)
BillingInvoiceSplitLineGroup(582-584)BillingInvoiceSplitLineGroup(586-591)BillingInvoiceSplitLineGroup(593-632)BillingInvoiceSplitLineGroup(634-641)BillingInvoiceSplitLineGroup(643-659)openmeter/ent/db/subscriptionitem/where.go (1)
ID(15-17)
⏰ Context from checks skipped due to timeout of 90000ms (1)
- GitHub Check: CI
🔇 Additional comments (118)
openmeter/ent/db/ent.go (1)
32-32: LGTM: Correct integration of new entity.The import and column validation registration for
BillingInvoiceSplitLineGroupfollows the established pattern and is placed in the correct alphabetical order within the existing structure.Also applies to: 137-137
openmeter/ent/db/tx.go (1)
49-50: LGTM: Proper transactional client integration.The
BillingInvoiceSplitLineGroupclient field and initialization follow the established pattern for other entity clients and maintain correct alphabetical ordering.Also applies to: 250-250
openmeter/ent/db/expose.go (1)
124-125: LGTM: Consistent client initialization.The
BillingInvoiceSplitLineGroupclient initialization follows the established pattern and maintains proper alphabetical ordering within the client structure.tools/migrate/migrations/20250609104934_billing-split-line-group.down.sql (1)
1-13: LGTM: Proper rollback migration structure.The migration script correctly reverses the schema changes in the proper order: foreign key constraints first, then indexes, and finally the table. This prevents constraint violations during rollback execution.
openmeter/ent/db/predicate/predicate.go (1)
112-124: LGTM: Consistent predicate implementation.The
BillingInvoiceSplitLineGrouppredicate type andBillingInvoiceSplitLineGroupOrErrhelper function follow the established pattern used for other entity predicates and maintain proper alphabetical ordering.openmeter/ent/db/hook/hook.go (1)
204-214: LGTM! Consistent adapter pattern implementation.The new
BillingInvoiceSplitLineGroupFuncadapter follows the exact same pattern as all other mutation adapters in this file, with proper type assertion and error handling.openmeter/ent/schema/subscription.go (3)
58-58: LGTM! Proper edge definition for Subscription entity.The new
billing_split_line_groupsedge establishes a clear one-to-many relationship to the BillingInvoiceSplitLineGroup entity.
105-105: LGTM! Consistent edge definition for SubscriptionPhase entity.The edge definition matches the pattern used in the Subscription entity, maintaining consistency across related entities.
201-201: LGTM! Consistent edge definition for SubscriptionItem entity.The edge definition follows the same pattern, completing the relationship model across all subscription-related entities.
openmeter/ent/db/subscription/where.go (1)
891-912: LGTM! Consistent predicate implementation for new edge.Both
HasBillingSplitLineGroupsandHasBillingSplitLineGroupsWithpredicates follow the established pattern used by all other edge predicates in this file, enabling proper relationship querying capabilities.openmeter/ent/db/subscriptionitem/where.go (1)
1288-1309: LGTM! New edge predicates follow established patterns correctly.The added predicates for the
billing_split_line_groupsedge are implemented consistently with the existing edge predicates in the file. The functions correctly:
- Use one-to-many (
sqlgraph.O2M) edge configuration- Follow the standard
HasEdgeandHasEdgeWithnaming pattern- Implement proper SQL graph traversal logic
- Maintain consistency with similar predicates like
HasBillingLinesSince this is generated code as part of the broader
BillingInvoiceSplitLineGroupentity integration, the implementation should be reliable.openmeter/ent/db/runtime.go (5)
25-25: LGTM: Import addition is correct.The import for the new
billinginvoicesplitlinegrouppackage is properly added and follows the established import pattern.
514-515: LGTM: Second mixin layer support added correctly.The addition of
billinginvoicelineMixinFields1properly supports the second mixin layer forBillingInvoiceLine, which is consistent with the schema changes introducing new fields through additional mixins.
533-533: LGTM: Field descriptor reference updated correctly.The currency field descriptor reference has been updated from
billinginvoicelineMixinFields0[2]tobillinginvoicelineMixinFields1[2]to reflect the new mixin structure where currency is now in the second mixin layer.
537-537: LGTM: Ratecard discounts field index updated.The field index for
ratecard_discountshas been updated tobillinginvoicelineFields[7], which reflects the correct position in the fields array after schema modifications.
603-637: LGTM: New entity initialization follows established patterns.The initialization code for
BillingInvoiceSplitLineGroupcorrectly follows the established patterns used throughout the file:
- Proper mixin handling with two mixin layers (ResourceMixin and InvoiceLineBaseMixin)
- Standard field descriptor setup for namespace, timestamps, and currency validation
- Correct value scanner configuration for complex types:
RatecardDiscountsusingfield.TypeValueScanner[*billing.Discounts]Priceusingfield.TypeValueScanner[*productcatalog.Price]- Default ID generator setup
The implementation is consistent with other entities in the codebase and properly handles the custom Go types with appropriate value scanners.
openmeter/ent/db/subscriptionphase/where.go (1)
752-773: LGTM! Clean implementation of billing split line groups predicates.The new predicate functions follow the established pattern perfectly, using the same sqlgraph approach as existing edge predicates like
HasBillingLines()andHasBillingLinesWith(). The implementation is consistent with the codebase conventions.openmeter/ent/db/subscriptionphase.go (3)
58-62: LGTM! Proper edge field addition and loadedTypes expansion.The new
BillingSplitLineGroupsedge field is correctly added to theSubscriptionPhaseEdgesstruct, and theloadedTypesarray is appropriately expanded from[3]boolto[4]boolto track the loading state of the new edge.
94-101: LGTM! Correct implementation of edge accessor method.The
BillingSplitLineGroupsOrErr()method follows the established pattern and correctly usesloadedTypes[3]for the new edge, maintaining consistency with other edge accessor methods.
236-239: LGTM! Consistent query method implementation.The
QueryBillingSplitLineGroups()method follows the same pattern as other edge query methods, properly delegating to the client's query method.openmeter/ent/db/subscription_create.go (3)
16-16: LGTM! Correct import addition.The import for the
billinginvoicesplitlinegrouppackage is properly added to support the new edge functionality.
229-242: LGTM! Consistent edge addition methods.The
AddBillingSplitLineGroupIDs()andAddBillingSplitLineGroups()methods follow the established pattern perfectly, matching the implementation style of other edge addition methods likeAddBillingLineIDs()andAddBillingLines().
511-526: LGTM! Proper SQL graph edge specification.The edge specification for
billing_split_line_groupscorrectly uses:
sqlgraph.O2M(one-to-many) relationship- Proper table and column references
- Correct target field specification
This maintains consistency with other edge specifications in the same method.
openmeter/ent/db/subscriptionitem.go (3)
83-87: LGTM! Consistent edge integration for SubscriptionItem.The
BillingSplitLineGroupsedge field andloadedTypesarray expansion follow the same pattern as implemented in other entity files, maintaining consistency across the codebase.
121-128: LGTM! Proper edge accessor implementation.The
BillingSplitLineGroupsOrErr()method correctly implements the edge accessor pattern, usingloadedTypes[3]for the new edge and following the established error handling approach.
345-348: LGTM! Consistent query method implementation.The
QueryBillingSplitLineGroups()method maintains consistency with other edge query methods and properly delegates to the client implementation.openmeter/ent/db/paginate.go (1)
780-826: Generated pagination method follows established patterns correctly.The new
Paginatemethod forBillingInvoiceSplitLineGroupQueryis correctly generated and follows the exact same implementation pattern as all other pagination methods in this file. The type check on line 826 ensures proper interface compliance.tools/migrate/migrations/20250609104934_billing-split-line-group.up.sql (3)
3-27: Well-structured table creation with appropriate schema design.The new
billing_invoice_split_line_groupstable schema is well-designed with:
- Standard entity fields (id, namespace, metadata, timestamps, soft delete)
- Domain-specific billing fields (period, currency, tax_config, price)
- Proper foreign key relationships to subscription entities
- Consistent use of
ON DELETE SET NULLfor maintaining data integrity
28-35: Excellent index strategy for performance and data integrity.The indexing strategy is well thought out:
- Unique index on
idfor primary key lookups- Namespace-based indexes for tenant isolation
- Conditional unique index on
namespace + unique_reference_idproperly handles soft-deleted records by excluding NULL values
37-37: Non-breaking foreign key addition to existing table.The addition of the nullable
split_line_group_idcolumn tobilling_invoice_linesis properly implemented:
- Nullable column ensures no breaking changes to existing data
- Foreign key constraint with
ON DELETE SET NULLmaintains referential integrity- Constraint naming follows established conventions
openmeter/ent/db/subscriptionitem_create.go (3)
16-16: LGTM: Import addition is correctly placed and necessary.The import for
billinginvoicesplitlinegrouppackage is properly added to support the new edge relationship functionality.
291-304: LGTM: Edge methods follow established patterns consistently.The new
AddBillingSplitLineGroupIDsandAddBillingSplitLineGroupsmethods are implemented correctly:
- Method signatures and parameter handling match existing edge methods
- ID extraction logic in
AddBillingSplitLineGroupsfollows the same pattern asAddBillingLines- Proper delegation to the underlying mutation object
610-625: LGTM: SQL graph creation logic is correctly implemented.The edge specification for
billing_split_line_groupsis properly configured:
- Uses appropriate O2M relationship type for one-to-many association
- References correct table/column constants and target ID specification
- Follows the same pattern as the existing
billing_linesedge aboveopenmeter/ent/db/subscriptionphase_create.go (3)
16-16: LGTM: Import addition is consistent and necessary.The import for
billinginvoicesplitlinegrouppackage is properly added, maintaining consistency with the corresponding changes insubscriptionitem_create.go.
185-198: LGTM: Edge methods are consistently implemented.The
AddBillingSplitLineGroupIDsandAddBillingSplitLineGroupsmethods maintain perfect consistency with:
- The corresponding methods in
subscriptionitem_create.go- Existing edge method patterns in this file
- Proper ID extraction and delegation logic
420-435: LGTM: SQL graph creation follows correct patterns.The edge specification is properly implemented:
- Consistent O2M relationship configuration with
subscriptionitem_create.go- Uses appropriate package constants for table and column references
- Correct target ID specification
- Maintains the established pattern for edge creation in this file
openmeter/ent/db/subscription/subscription.go (4)
51-52: LGTM! Edge constant follows established naming conventions.The new
EdgeBillingSplitLineGroupsconstant maintains consistency with existing edge naming patterns.
85-91: LGTM! Table and column constants are correctly defined.The relationship constants properly reference the
billing_invoice_split_line_groupstable withsubscription_idas the foreign key column, maintaining consistency with the database schema.
262-274: LGTM! Ordering functions follow established patterns.Both
ByBillingSplitLineGroupsCountandByBillingSplitLineGroupscorrectly implement the ordering interface usingsqlgraph.OrderByNeighborsCountandsqlgraph.OrderByNeighborTermsrespectively, consistent with other edge ordering functions.
317-323: LGTM! SQL graph step correctly defines the relationship.The
newBillingSplitLineGroupsStep()function properly configures a one-to-many (sqlgraph.O2M) relationship from subscription to billing split line groups with correct table and column references.openmeter/ent/db/subscriptionphase/subscriptionphase.go (4)
45-46: LGTM! Edge constant maintains consistency.The
EdgeBillingSplitLineGroupsconstant follows the same naming convention as the subscription entity.
70-76: LGTM! Relationship constants are entity-appropriate.The constants correctly use
subscription_phase_idas the foreign key column, properly linking billing split line groups to subscription phases.
217-229: LGTM! Ordering functions maintain established patterns.Both ordering functions correctly implement the same interface pattern as other entities, ensuring consistent query behavior across the schema.
251-257: LGTM! SQL graph step properly configured.The step function correctly defines the one-to-many relationship with the appropriate foreign key column for subscription phases.
openmeter/ent/db/billinginvoicesplitlinegroup_delete.go (4)
15-26: LGTM! Delete builder follows standard Ent patterns.The
BillingInvoiceSplitLineGroupDeletestruct andWheremethod correctly implement the standard Ent delete builder interface.
28-40: LGTM! Execution methods properly handle hooks and errors.Both
ExecandExecXmethods follow the established pattern with proper hook integration and panic-on-error behavior.
42-57: LGTM! SQL execution correctly implements delete logic.The
sqlExecmethod properly constructs the delete specification usingsqlgraph.NewDeleteSpecwith correct table and field references, and includes appropriate constraint error handling.
59-88: LGTM! Single delete builder properly handles not found case.The
BillingInvoiceSplitLineGroupDeleteOneimplementation correctly returnsNotFoundErrorwhen no entity is affected, following the standard Ent pattern for single entity operations.openmeter/ent/db/subscription.go (5)
66-67: LGTM! New edge properly added to edges struct.The
BillingSplitLineGroupsedge correctly follows the established pattern for slice-type edges.
72-72: LGTM! LoadedTypes array correctly expanded.The array size increased from 5 to 6 to accommodate the new edge loading state tracking.
115-122: LGTM! Edge accessor follows established pattern.The
BillingSplitLineGroupsOrErr()method correctly implements the standard edge accessor pattern with appropriate error handling for unloaded edges.
127-127: LGTM! Index correctly updated for array expansion.The
AddonsOrErr()method properly updated itsloadedTypesindex from 4 to 5 to account for the new edge insertion.
284-287: LGTM! Query method follows established pattern.The
QueryBillingSplitLineGroups()method correctly delegates to the subscription client, maintaining consistency with other edge query methods.openmeter/ent/db/subscriptionitem/subscriptionitem.go (3)
69-70: Edge constants properly defined following established patterns.The new
EdgeBillingSplitLineGroupsconstant and related table/column constants follow the exact same pattern as existing edges likeEdgeBillingLines, ensuring consistency in the codebase.Also applies to: 94-100
308-320: Ordering functions correctly implemented.The
ByBillingSplitLineGroupsCountandByBillingSplitLineGroupsfunctions follow the same pattern as existing ordering functions, using the appropriate sqlgraph methods for neighbor counting and term ordering.
342-348: Graph step creation follows correct pattern.The
newBillingSplitLineGroupsStepfunction correctly defines an O2M (one-to-many) relationship from subscription items to billing split line groups, which is the appropriate relationship type for this use case.openmeter/ent/db/subscription_update.go (4)
15-15: Import correctly added for new entity package.The import for
billinginvoicesplitlinegrouppackage is properly added to support the new edge relationship operations.
197-210: Add methods properly implemented for both update builders.The
AddBillingSplitLineGroupIDsandAddBillingSplitLineGroupsmethods are correctly implemented for bothSubscriptionUpdateandSubscriptionUpdateOne, following the exact same pattern as existing edge add methods.Also applies to: 806-819
280-299: Clear and remove methods consistently implemented.The clear and remove methods for
billing_split_line_groupsedge follow the established patterns, providing complete edge management functionality for both update builders.Also applies to: 889-908
535-579: SQL edge specifications correctly implemented.The edge specifications in both
sqlSavemethods properly handle the O2M relationship using the correct table (subscription.BillingSplitLineGroupsTable) and column (subscription.BillingSplitLineGroupsColumn) constants, following the same pattern as existing edge relationships.Also applies to: 1174-1218
openmeter/ent/db/subscriptionitem_update.go (6)
15-15: LGTM: Import addition is consistent with new entity support.The import for the new
billinginvoicesplitlinegrouppackage is correctly added to support the new edge functionality.
342-355: LGTM: Edge management methods follow established patterns.The
AddBillingSplitLineGroupIDsandAddBillingSplitLineGroupsmethods follow the same implementation pattern as other edge management methods in the file, properly delegating to the mutation layer and handling ID extraction.
389-408: LGTM: Clear and remove methods are correctly implemented.The clear and remove methods for the billing split line groups edge follow the established patterns for edge management, providing both ID-based and entity-based variants.
678-722: LGTM: SQL edge specifications are correctly defined.The SQL save logic properly handles the new edge relationship with:
- Correct relationship type (O2M, inverse=false)
- Proper table and column references
- Consistent edge clearing, removal, and addition logic following the same pattern as the "billing_lines" edge
1049-1115: LGTM: SubscriptionItemUpdateOne methods mirror the bulk update functionality.The edge management methods for
SubscriptionItemUpdateOnecorrectly mirror the functionality provided bySubscriptionItemUpdate, maintaining consistency between single and bulk update operations.
1415-1459: LGTM: SQL logic for single entity updates is consistent.The SQL save logic for
SubscriptionItemUpdateOneproperly implements the same edge management patterns as the bulk update variant, ensuring consistent behavior across different update operations.openmeter/ent/db/billinginvoiceline_query.go (9)
21-21: LGTM: Import addition supports new edge functionality.The import for
billinginvoicesplitlinegrouppackage is correctly added to enable query operations on the new edge relationship.
37-37: LGTM: Query field addition follows established pattern.The
withSplitLineGroupfield is properly added to the query struct, following the same naming convention and type pattern as other edge query fields.
107-127: LGTM: Query chaining method is correctly implemented.The
QuerySplitLineGroupmethod properly implements query chaining for the split line group edge with:
- Correct edge configuration (M2O, inverse=true)
- Proper table and column references
- Consistent error handling and SQL graph setup
520-520: LGTM: Clone method updated to include new field.The clone operation correctly includes the
withSplitLineGroupfield to ensure proper query builder cloning behavior.
547-556: LGTM: Eager-loading method follows established pattern.The
WithSplitLineGroupmethod correctly implements eager-loading functionality with proper query builder configuration and option handling.
736-748: LGTM: LoadedTypes array properly updated.The
loadedTypesarray size is correctly updated from 10 to 11, and the new boolean forwithSplitLineGroupis properly positioned in the array to maintain consistency with the loading logic.
783-788: LGTM: Eager-loading integration is correctly implemented.The eager-loading logic for the split line group is properly integrated into the
sqlAllmethod, following the same pattern as other many-to-one relationships.
884-915: LGTM: Loading method properly handles nullable foreign key.The
loadSplitLineGroupmethod correctly implements the loading logic with:
- Proper null check for the optional
SplitLineGroupIDfield (lines 888-890)- Correct foreign key handling and batch loading
- Appropriate error handling for unexpected foreign key values
- Consistent implementation pattern matching other loading methods
1234-1236: LGTM: Query specification includes foreign key column when needed.The query spec method correctly adds the
SplitLineGroupIDcolumn when the split line group edge is being eagerly loaded, ensuring the foreign key is available for the loading process.openmeter/ent/db/billinginvoicesplitlinegroup/where.go (1)
1-1150: LGTM!This auto-generated predicate file follows standard Ent framework patterns and provides comprehensive filtering capabilities for the new
BillingInvoiceSplitLineGroupentity.openmeter/ent/db/subscription_query.go (1)
17-17: LGTM!The integration of the
billing_split_line_groupsedge follows the established patterns for O2M relationships in the query builder. The implementation is consistent with other edges in terms of query methods, eager loading, and error handling.Also applies to: 29-38, 164-184, 395-405, 456-465, 556-562, 612-620, 756-788
openmeter/ent/db/billinginvoiceline.go (1)
18-18: LGTM!The integration of new fields (
PeriodStart,PeriodEnd,Currency,TaxConfig) and theSplitLineGroupedge is properly implemented. The nullable foreign keySplitLineGroupIDis correctly handled, and all edge indices have been properly updated throughout the file.Also applies to: 46-53, 94-95, 112-113, 134-134, 148-157, 263-263, 340-365, 493-499, 539-542, 637-648, 725-729
openmeter/ent/db/subscriptionphase_update.go (6)
15-15: LGTM - Import added for new entity support.The import for
billinginvoicesplitlinegrouppackage is correctly added to support the new edge operations.
163-176: LGTM - Add methods follow established patterns.The
AddBillingSplitLineGroupIDsandAddBillingSplitLineGroupsmethods correctly follow the same implementation pattern used for other edges likebilling_lines.
225-244: LGTM - Clear and remove methods implemented correctly.The clear and remove operations for
billing_split_line_groupsedge are implemented consistently with existing edge patterns, providing proper entity and ID-based removal methods.
430-474: LGTM - SQL edge handling follows correct patterns.The SQL generation for the
billing_split_line_groupsedge operations (clear, remove, add) correctly usessqlgraph.EdgeSpecwith proper relationship configuration (O2M, non-inverse) matching the schema definition.
624-637: LGTM - Single entity update methods implemented consistently.The
SubscriptionPhaseUpdateOnebuilder includes the same complete set of methods for managing thebilling_split_line_groupsedge, maintaining consistency with the bulk update builder.Also applies to: 686-705
921-965: LGTM - Single entity SQL operations match bulk operations.The SQL edge handling in
SubscriptionPhaseUpdateOne.sqlSavecorrectly mirrors the bulk operation logic, ensuring consistent behavior across both update builders.openmeter/ent/db/billinginvoiceline/billinginvoiceline.go (6)
34-41: LGTM - New field constants follow established conventions.The new field constants (
FieldPeriodStart,FieldPeriodEnd,FieldCurrency,FieldTaxConfig,FieldSplitLineGroupID) are properly defined following the existing naming pattern and are correctly positioned in the constants section.Also applies to: 82-83
88-89: LGTM - Edge and relationship constants properly defined.The
EdgeSplitLineGroupconstant and related table/column definitions (SplitLineGroupTable,SplitLineGroupInverseTable,SplitLineGroupColumn) correctly establish the relationship metadata following Ent conventions.Also applies to: 117-123
193-196: LGTM - Columns slice updated to include new fields.The
Columnsslice is properly updated to include all new fields (FieldPeriodStart,FieldPeriodEnd,FieldCurrency,FieldTaxConfig,FieldSplitLineGroupID), ensuring they are available for database operations.Also applies to: 217-217
334-347: LGTM - Ordering functions implemented consistently.The ordering functions for new fields (
ByPeriodStart,ByPeriodEnd,ByCurrency,BySplitLineGroupID) follow the established pattern usingsql.OrderByFieldand proper option handling.Also applies to: 449-452
466-471: LGTM - Edge ordering function correctly implemented.The
BySplitLineGroupFieldfunction properly usessqlgraph.OrderByNeighborTermswith thenewSplitLineGroupStep()helper, following the same pattern as other edge ordering functions.
563-569: LGTM - SQL graph step function correctly defines relationship.The
newSplitLineGroupStep()function properly defines the many-to-one relationship usingsqlgraph.M2Owith correct table and column references, enabling proper SQL generation for edge traversal.openmeter/ent/db/subscriptionitem_query.go (7)
17-17: LGTM - Import added for new entity support.The import for
billinginvoicesplitlinegrouppackage is correctly added to support the new edge query operations.
34-34: LGTM - Query struct updated with new edge field.The
withBillingSplitLineGroupsfield is properly added to theSubscriptionItemQuerystruct to track eager-loading state for the new edge.
138-158: LGTM - Query chaining method implemented correctly.The
QueryBillingSplitLineGroupsmethod properly implements query chaining for the new edge, following the same pattern as other edge query methods with correct SQL graph step configuration.
355-355: LGTM - Clone method updated to preserve edge state.The
Clonemethod correctly includes the newwithBillingSplitLineGroupsfield in the cloning operation, ensuring all query state is properly preserved.
395-404: LGTM - Eager loading method implemented consistently.The
WithBillingSplitLineGroupsmethod properly implements eager loading configuration for the new edge, following the established pattern with option handling and query setup.
484-488: LGTM - SQL loading logic properly integrated.The
sqlAllmethod correctly updates theloadedTypesarray size to 4 and includes proper loading logic for thebilling_split_line_groupsedge with appropriate initialization and assignment functions.Also applies to: 533-541
640-672: LGTM - Batch loading method implemented correctly.The
loadBillingSplitLineGroupsmethod properly implements batched loading for the new edge relationship, following the same foreign key pattern as other edges with correct error handling and node assignment.openmeter/ent/db/subscriptionphase_query.go (1)
17-671: LGTM! The billing split line groups edge integration is correctly implemented.The changes properly integrate the new
billing_split_line_groupsedge into theSubscriptionPhasequery builder, following the established patterns for edge management in the ent framework. The implementation includes:
- Correct array size adjustment for loaded types tracking
- Proper O2M (One-to-Many) relationship configuration
- Consistent error handling with nil foreign key checks
- Standard eager-loading and query chaining support
openmeter/ent/db/billinginvoicesplitlinegroup/billinginvoicesplitlinegroup.go (1)
1-298: LGTM! Standard ent-generated entity metadata.This auto-generated file correctly defines the schema constants, validators, and ordering functions for the new
BillingInvoiceSplitLineGroupentity. The edge definitions properly establish relationships with:
billing_invoice_lines(O2M)subscription(M2O)subscription_phase(M2O)subscription_item(M2O)openmeter/ent/db/billinginvoicesplitlinegroup.go (1)
1-411: LGTM! Well-structured entity model with comprehensive edge support.The auto-generated
BillingInvoiceSplitLineGroupentity properly implements:
- Appropriate field types including domain-specific types (
currencyx.Code,productcatalog.TaxConfig)- Robust edge accessor methods with proper error handling for unloaded edges
- Correct SQL scanning for nullable fields and JSON unmarshalling for complex types
- Standard query, update, and transaction unwrapping methods
The entity successfully encapsulates the split line group concept for organizing billing invoice lines by subscription context.
openmeter/ent/db/migrate/schema.go (3)
736-739: Column reordering looks good.The reordering of
period_start,period_end,currency, andtax_configcolumns to appear earlier in the column definition provides better logical grouping of related billing fields.
760-760: Foreign key relationship properly implemented.The new
split_line_group_idcolumn and its foreign key constraint toBillingInvoiceSplitLineGroupstable are correctly defined withSetNullon delete, which is appropriate for an optional relationship.Also applies to: 795-800
974-1046: New table structure is well-designed.The
BillingInvoiceSplitLineGroupstable follows the established patterns with:
- Proper column definitions and types
- Appropriate foreign key constraints with
SetNullon delete- Comprehensive indexes including a unique constraint on
namespace+unique_reference_idwith soft delete supportopenmeter/ent/schema/billing.go (2)
295-318: Well-structured mixin for common invoice line fieldsThe
InvoiceLineBaseMixineffectively encapsulates shared fields between invoice lines and split line groups, promoting code reuse and consistency.
582-659:Details
❓ Verification inconclusive
Verify the unique index strategy for split line groups
The unique index on
(namespace, unique_reference_id)with the conditionunique_reference_id IS NOT NULL AND deleted_at IS NULLallows multiple null values, which is appropriate for optional fields. However, ensure that theunique_reference_idgeneration logic is well-defined to prevent conflicts.
🏁 Script executed:
#!/bin/bash # Check how unique_reference_id is generated and used in the codebase rg -A 5 "unique_reference_id" --type goLength of output: 73248
Ensure collision-free generation of unique_reference_id for split line groups
The partial unique index on
(namespace, unique_reference_id)with the condition
unique_reference_id IS NOT NULL AND deleted_at IS NULLcorrectly allows multiple NULLs while enforcing uniqueness when populated. Since the Ent schema does not auto-generate this field, please verify in your creation logic that you consistently setunique_reference_idto a globally unique value (for example, a UUID or other deterministic ID) before persisting.• Schema location:
openmeter/ent/schema/billing.go–BillingInvoiceSplitLineGroup.Fields()&Indexes()
• Migration index:ent/db/migrate/schema.go–billinginvoicesplitlinegroup_namespace_unique_reference_idopenmeter/ent/db/billinginvoiceline_update.go (1)
1-2585: Generated code changes are consistent and well-structuredThe update operations for the new fields (
period_start,period_end,tax_config) and thesplit_line_groupedge follow Ent's established patterns correctly. The validation forTaxConfig(lines 782-786, 2054-2058) ensures data integrity.openmeter/ent/db/client.go (6)
34-34: Import correctly added.The new import follows the established pattern and maintains alphabetical ordering.
102-103: Client integration follows established patterns.The new entity client is properly integrated across all initialization points, hooks, interceptors, and mutation handling, maintaining consistency with other entities in the codebase.
Also applies to: 183-183, 318-318, 380-380, 441-441, 463-463, 511-512
2951-2965: Edge query method properly implemented.The
QuerySplitLineGroupmethod correctly implements the many-to-one relationship from BillingInvoiceLine to BillingInvoiceSplitLineGroup.
3434-3629: Complete entity client implementation.The BillingInvoiceSplitLineGroupClient provides all standard CRUD operations and edge queries, following the established Ent framework patterns consistently.
7087-7101: Subscription edge queries correctly implemented.The
QueryBillingSplitLineGroupsmethods on Subscription, SubscriptionItem, and SubscriptionPhase clients properly implement the one-to-many relationships to BillingInvoiceSplitLineGroup.Also applies to: 7630-7644, 7827-7841
8025-8025: Hook and interceptor types updated correctly.The new entity is properly added to both the hooks and interceptors type definitions, maintaining alphabetical ordering.
Also applies to: 8039-8039
openmeter/ent/db/billinginvoicesplitlinegroup_query.go (1)
1-884: Generated query builder looks good.This auto-generated file correctly implements the query builder for the new
BillingInvoiceSplitLineGroupentity with proper support for edges, eager loading, aggregation, and concurrency control.openmeter/ent/db/setorclear.go (1)
1024-1037: SetOrClear methods correctly implemented.The new
SetOrClearmethods forBillingInvoiceLineandBillingInvoiceSplitLineGroupfollow the established pattern and properly handle nullable fields. This supports the schema changes for the new split line group functionality.Also applies to: 1150-1163, 1388-1527
openmeter/ent/db/billinginvoiceline_create.go (1)
1-2762: LGTM!The auto-generated code correctly implements the new
BillingInvoiceSplitLineGroupintegration with proper:
- Field setters for
period_start,period_end,currency,tax_config, andsplit_line_group_id- Edge relationship configuration for the M2O
split_line_groupedge- Field validation including currency format and tax config validation
- Consistent upsert operation support for all new fields
openmeter/ent/db/billinginvoicesplitlinegroup_create.go (1)
837-854: Good design: Currency field is immutable during upsertsThe
UpdateNewValues()method correctly treats thecurrencyfield as immutable alongsideID,Namespace, andCreatedAt. This prevents accidental currency changes during updates, which is a good practice for maintaining data consistency in billing systems.openmeter/ent/db/billinginvoiceline/where.go (1)
1-2127: Generated code follows consistent patternsThe predicate implementations for the new fields (
PeriodStart,PeriodEnd,Currency,TaxConfig,SplitLineGroupID) and edges (SplitLineGroup) are correctly generated and follow the established patterns in the codebase.openmeter/ent/db/billinginvoicesplitlinegroup_update.go (1)
1-1208: Update builders properly implementedThe update builders for
BillingInvoiceSplitLineGroupare correctly generated with:
- Comprehensive field setters with proper nil handling
- Correct edge management for both O2M (billing_invoice_lines) and M2O (subscription relationships) edges
- Appropriate error handling and constraint error wrapping
- Proper value scanning for complex types
|
|
||
| // Subscriptions metadata | ||
| field.String("subscription_id"). | ||
| Optional(). |
There was a problem hiding this comment.
Actionable comments posted: 0
♻️ Duplicate comments (2)
openmeter/ent/schema/billing.go (2)
612-615: Review comment has been addressed.The immutable flags have been added to
feature_keyandpricefields as requested in the past review comments.Also applies to: 617-622
625-638: Good use of immutable constraints.The subscription metadata fields (
subscription_id,subscription_phase_id,subscription_item_id) are correctly marked as immutable, as noted in the past review. This prevents accidental modifications to these reference fields.
🧹 Nitpick comments (3)
openmeter/ent/schema/billing.go (3)
331-333: Track the TODO for field renaming.The TODO comment indicates that
period_startandperiod_endshould be renamed toservice_period_startandservice_period_endfor consistency. This should be tracked to ensure the migration is completed.Would you like me to create an issue to track this field renaming task?
403-409: Consider the design implications of the split_line_group_id field.The comment indicates this field is "only valid for ubp lines" but is added to the general
BillingInvoiceLinetable. This suggests that the table might eventually be split or specialized. Consider whether this field should be part of a more specific entity or if the current design is a stepping stone to a future refactoring.
599-601: Consider adding validation for unique_reference_id format.Based on the past review comments, this field has a specific format like
01JMAY1MBNCBHZ9WZ2CM7GFESQ/default/input_tokens_used/v[0]/period[0]. Consider adding a validation function to ensure the format is correct when the field is populated.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
tools/migrate/migrations/atlas.sumis excluded by!**/*.sum
📒 Files selected for processing (16)
openmeter/ent/db/billinginvoiceline.go(23 hunks)openmeter/ent/db/billinginvoiceline/billinginvoiceline.go(10 hunks)openmeter/ent/db/billinginvoiceline/where.go(7 hunks)openmeter/ent/db/billinginvoiceline_create.go(21 hunks)openmeter/ent/db/billinginvoiceline_update.go(19 hunks)openmeter/ent/db/billinginvoicesplitlinegroup.go(1 hunks)openmeter/ent/db/billinginvoicesplitlinegroup/billinginvoicesplitlinegroup.go(1 hunks)openmeter/ent/db/billinginvoicesplitlinegroup/where.go(1 hunks)openmeter/ent/db/billinginvoicesplitlinegroup_create.go(1 hunks)openmeter/ent/db/billinginvoicesplitlinegroup_update.go(1 hunks)openmeter/ent/db/migrate/schema.go(7 hunks)openmeter/ent/db/runtime.go(4 hunks)openmeter/ent/db/setorclear.go(3 hunks)openmeter/ent/schema/billing.go(4 hunks)tools/migrate/migrations/20250609172811_billing-split-line-group.down.sql(1 hunks)tools/migrate/migrations/20250609172811_billing-split-line-group.up.sql(1 hunks)
✅ Files skipped from review due to trivial changes (1)
- tools/migrate/migrations/20250609172811_billing-split-line-group.down.sql
🚧 Files skipped from review as they are similar to previous changes (7)
- openmeter/ent/db/billinginvoicesplitlinegroup/where.go
- openmeter/ent/db/billinginvoiceline/billinginvoiceline.go
- openmeter/ent/db/billinginvoicesplitlinegroup.go
- openmeter/ent/db/runtime.go
- openmeter/ent/db/migrate/schema.go
- openmeter/ent/db/billinginvoiceline.go
- openmeter/ent/db/setorclear.go
🧰 Additional context used
🧬 Code Graph Analysis (2)
openmeter/ent/db/billinginvoicesplitlinegroup_update.go (9)
openmeter/ent/db/ent.go (7)
Hook(66-66)Mutation(78-78)Value(67-67)NotFoundError(284-286)IsConstraintError(367-373)ConstraintError(351-354)ValidationError(259-262)openmeter/ent/db/mutation.go (1)
BillingInvoiceSplitLineGroupMutation(21698-21731)openmeter/ent/db/billinginvoicesplitlinegroup.go (2)
BillingInvoiceSplitLineGroup(23-67)BillingInvoiceSplitLineGroup(127-146)openmeter/ent/schema/billing.go (10)
BillingInvoiceSplitLineGroup(583-585)BillingInvoiceSplitLineGroup(587-592)BillingInvoiceSplitLineGroup(594-640)BillingInvoiceSplitLineGroup(642-649)BillingInvoiceSplitLineGroup(651-670)BillingInvoiceLine(317-319)BillingInvoiceLine(321-327)BillingInvoiceLine(329-420)BillingInvoiceLine(422-432)BillingInvoiceLine(434-475)openmeter/ent/db/predicate/predicate.go (2)
BillingInvoiceSplitLineGroup(113-113)BillingInvoiceLine(71-71)openmeter/ent/db/billinginvoiceline.go (2)
BillingInvoiceLine(28-106)BillingInvoiceLine(253-278)openmeter/ent/db/billinginvoicesplitlinegroup/where.go (8)
ID(15-17)UpdatedAt(80-82)DeletedAt(85-87)Name(90-92)Description(95-97)ServicePeriodStart(106-108)ServicePeriodEnd(111-113)UniqueReferenceID(116-118)openmeter/ent/db/billinginvoicesplitlinegroup/billinginvoicesplitlinegroup.go (17)
Table(65-65)Columns(97-117)FieldID(19-19)FieldMetadata(23-23)FieldUpdatedAt(27-27)FieldDeletedAt(29-29)FieldName(31-31)FieldDescription(33-33)FieldTaxConfig(37-37)FieldServicePeriodStart(39-39)FieldServicePeriodEnd(41-41)FieldUniqueReferenceID(43-43)ValueScanner(143-146)FieldRatecardDiscounts(45-45)FieldFeatureKey(47-47)BillingInvoiceLinesTable(67-67)BillingInvoiceLinesColumn(72-72)openmeter/ent/db/migrate/schema.go (1)
BillingInvoiceLinesTable(766-860)
openmeter/ent/db/billinginvoiceline_create.go (8)
pkg/currencyx/currency.go (1)
Code(12-12)openmeter/productcatalog/tax.go (1)
TaxConfig(36-39)openmeter/ent/db/billinginvoiceline/where.go (6)
ID(17-19)Currency(102-105)Name(92-94)PeriodStart(143-145)PeriodEnd(148-150)SplitLineGroupID(198-200)openmeter/ent/db/billinginvoicesplitlinegroup/where.go (3)
ID(15-17)Currency(100-103)Name(90-92)openmeter/ent/db/ent.go (1)
ValidationError(259-262)openmeter/billing/errors.go (1)
ValidationError(119-119)openmeter/ent/db/billinginvoiceline/billinginvoiceline.go (11)
CurrencyValidator(257-257)FieldCurrency(35-35)FieldTaxConfig(37-37)FieldManagedBy(59-59)Table(109-109)Columns(184-218)FieldID(19-19)FieldPeriodStart(53-53)FieldPeriodEnd(55-55)FieldSplitLineGroupID(83-83)FieldType(65-65)openmeter/ent/db/billinginvoicesplitlinegroup/billinginvoicesplitlinegroup.go (6)
CurrencyValidator(139-139)FieldCurrency(35-35)FieldTaxConfig(37-37)Table(65-65)Columns(97-117)FieldID(19-19)
⏰ Context from checks skipped due to timeout of 90000ms (13)
- GitHub Check: Analyze (javascript)
- GitHub Check: Analyze (go)
- GitHub Check: Artifacts / Benthos Collector Container image
- GitHub Check: Artifacts / Container image
- GitHub Check: Commit hooks
- GitHub Check: Quickstart
- GitHub Check: Lint
- GitHub Check: Developer environment
- GitHub Check: E2E
- GitHub Check: CI
- GitHub Check: Build
- GitHub Check: Migration Checks
- GitHub Check: Test
🔇 Additional comments (39)
tools/migrate/migrations/20250609172811_billing-split-line-group.up.sql (3)
1-26: Well-designed table schema with proper relationships and constraints.The new
billing_invoice_split_line_groupstable follows excellent database design practices:
- Appropriate data types for all fields (character(26) for ULID IDs, jsonb for flexible data)
- Comprehensive field set covering business requirements (currency, tax config, service periods, pricing)
- Proper foreign key relationships to subscription-related tables with SET NULL on delete
- Consistent with existing schema patterns in the codebase
27-34: Excellent index strategy for performance and data integrity.The indexing approach is well thought out:
- Unique index on ID for primary key enforcement
- Namespace index for tenant-based queries
- Composite unique index on (namespace, id) for efficient lookups
- Conditional unique index ensuring uniqueness of reference IDs only for active, non-deleted records
The partial index condition
(unique_reference_id IS NOT NULL) AND (deleted_at IS NULL)is particularly well-designed for supporting soft deletes while maintaining business constraints.
35-36: Clean integration with existing table structure.The modification to
billing_invoice_linesproperly establishes the relationship:
- Nullable foreign key allows optional association with split line groups
- Foreign key constraint ensures referential integrity
- SET NULL on delete prevents orphaned references while preserving data integrity
openmeter/ent/db/billinginvoiceline_update.go (11)
21-21: Correct import for the new entity.Properly imports the
billinginvoicesplitlinegrouppackage to support the new relationship.
115-133: Good code consolidation for tax_config field.The consolidation of setter, nillable setter, and clearer methods for
tax_configremoves duplication and follows a cleaner pattern. This is consistent with how other similar fields should be handled.
233-259: Clean consolidation of period field setters.The refactoring of
period_startandperiod_endsetters eliminates code duplication while maintaining the same functionality. This follows the established pattern used elsewhere in the codebase.
469-487: Standard field setter implementation for split_line_group_id.The implementation follows Ent patterns correctly:
- Regular setter for direct value assignment
- Nillable setter for optional value handling
- Clearer method for removing the association
- Consistent naming and method signatures
520-523: Proper edge setter implementation.The
SetSplitLineGroupmethod correctly establishes the relationship by using the entity's ID, following the standard Ent pattern for M2O relationships.
639-643: Appropriate edge clearer method.The
ClearSplitLineGroupmethod properly removes the edge relationship, maintaining consistency with other similar edge management methods.
782-786: Proper validation integration.The validation check for
tax_configusingv.Validate()is correctly integrated into the check method, ensuring data integrity during updates.
944-972: Correct SQL edge specification for split_line_group.The SQL edge handling properly:
- Uses M2O relationship with inverse=true indicating the foreign key is on this side
- References the correct table and column names from the migration
- Handles both clearing and adding edge operations
- Follows the established pattern for similar relationships
1728-1746: Consistent implementation in UpdateOne builder.The
BillingInvoiceLineUpdateOnebuilder includes the same complete set of methods for managing thesplit_line_group_idfield, maintaining consistency between bulk and single update operations.
1779-1782: Proper edge setter in UpdateOne builder.The single-entity update builder correctly implements the same edge management pattern as the bulk update builder.
2233-2261: Correct SQL implementation in UpdateOne.The single-entity update SQL generation correctly mirrors the bulk update implementation, ensuring consistent behavior across both update patterns.
openmeter/ent/schema/billing.go (2)
295-316: Good refactoring to extract common invoice line fields.The introduction of
InvoiceLineBaseMixinproperly encapsulates common fields (currencyandtax_config) that are shared between invoice line entities. This follows the DRY principle and improves maintainability.Also applies to: 324-324
642-649: Well-designed unique constraint.The unique partial index on
(namespace, unique_reference_id)with the conditionunique_reference_id IS NOT NULL AND deleted_at IS NULLis properly implemented. This ensures uniqueness only for non-deleted entries with a reference ID.openmeter/ent/db/billinginvoicesplitlinegroup/billinginvoicesplitlinegroup.go (1)
1-299: Generated code looks correct.This is auto-generated code by Ent framework that properly implements the schema defined in
billing.go. No manual changes should be made to this file.openmeter/ent/db/billinginvoiceline_create.go (8)
22-22: LGTM: Import addition for split line group relationshipThe import is properly positioned and necessary for the new edge relationship to
BillingInvoiceSplitLineGroup.
113-117: LGTM: New field setter methods are well-implementedThe setter methods follow Ent's standard patterns and provide appropriate nullable variants for optional fields. The type usage is consistent with the schema definition.
Also applies to: 119-131, 175-185, 321-333
374-377: LGTM: Edge setter method correctly implementedThe
SetSplitLineGroupmethod follows Ent's standard pattern for establishing relationships via foreign key assignment.
690-697: LGTM: Database spec generation correctly implementedThe
createSpec()method properly handles the new fields and edge relationship. The many-to-one relationship configuration and pointer assignment for optionalSplitLineGroupIDare correctly implemented.Also applies to: 726-733, 791-807
1088-1104: LGTM: Upsert methods comprehensively implementedAll upsert builders (single, bulk) include proper setter, updater, and clearer methods for the new fields. The implementation maintains consistency across all upsert operation types.
Also applies to: 1190-1212, 1406-1422, 1593-1612, 1712-1738, 1964-1983, 2327-2346, 2446-2472, 2698-2717
1-2762: LGTM: Comprehensive and consistent implementationThe changes successfully add support for new fields (
currency,tax_config,period_start,period_end,split_line_group_id) and thesplit_line_groupedge relationship. The implementation:
- Follows Ent framework patterns consistently
- Includes proper validation for required fields
- Handles optional fields with nullable setters
- Implements complete CRUD and upsert support
- Configures the database relationship correctly
The generated code appears to correctly implement the schema changes described in the PR objectives.
1465-1470:Details
❓ Verification inconclusive
LGTM: Immutable field handling in upsert operations
Adding
currencyandtypefields to the ignore list inUpdateNewValuessuggests these are intended to be immutable after creation, which is a reasonable design choice for key identifying fields.Verify that making currency and type immutable in upsert operations aligns with business requirements:
Also applies to: 2198-2203
🏁 Script executed:
#!/bin/bash # Search for any existing usage patterns of currency updates rg -A 3 -B 3 "SetCurrency|UpdateCurrency" --type goLength of output: 20136
🏁 Script executed:
#!/bin/bash # Search for any existing usage patterns of type updates rg -A 3 -B 3 "SetType|UpdateType" --type goLength of output: 54246
Immutable Currency and Type Ignored on Upsert—Confirm Business Requirements
- Verified that
UpdateNewValuesnow ignoresbillinginvoiceline.FieldCurrencyandbillinginvoiceline.FieldTypewhen resolving conflicts:
- File:
openmeter/ent/db/billinginvoiceline_create.go, lines 1465–1470- File:
openmeter/ent/db/billinginvoiceline_create.go, lines 2198–2203- Searches show
SetCurrency/UpdateCurrencyandSetType/UpdateTypeexist for other entities’ upserts, but will not apply here due to the new ignore logic.Please confirm that currency and type must remain immutable on billing invoice line upserts per your business rules.
550-562:Details
✅ Verification successful
LGTM: Validation logic properly implemented
The validation correctly enforces required fields and applies appropriate validators. The currency conversion to string and tax config's
Validate()method call are properly implemented.Verify that the
productcatalog.TaxConfig.Validate()method provides comprehensive validation:Also applies to: 584-589
🏁 Script executed:
#!/bin/bash # Search for the TaxConfig Validate method implementation ast-grep --pattern 'func ($$$) Validate() error { $$$ }'Length of output: 69177
To pinpoint the
TaxConfigtype and itsValidate()implementation, let’s inspect the mutation accessor and the type definition:
🏁 Script executed:
#!/bin/bash # 1. Locate the TaxConfig accessor in the billing invoice line mutation grep -n -C3 'TaxConfig' openmeter/ent/db/billinginvoiceline_mutation.go || true # 2. Find where TaxConfig is declared anywhere in the repo rg -n 'type TaxConfig' -n . # 3. Search specifically for a Validate() method on TaxConfig ast-grep --pattern $'func ($_ TaxConfig) Validate() error { $$$ }'Length of output: 534
Let’s inspect the
TaxConfigdefinition and itsValidate()implementation inopenmeter/productcatalog/tax.go:
🏁 Script executed:
#!/bin/bash # 1. Locate the TaxConfig type grep -n '^type TaxConfig' openmeter/productcatalog/tax.go # 2. See if a Validate method is defined on TaxConfig grep -n 'func .*TaxConfig.*Validate' openmeter/productcatalog/tax.go || true # 3. Dump the first 200 lines of the file for context sed -n '1,200p' openmeter/productcatalog/tax.goLength of output: 2747
✅ Validation logic approved – TaxConfig.Validate is comprehensive
TaxConfig.Validatechecks bothBehavior(if set) andStripesub-config, aggregating all errors.StripeTaxConfig.Validateenforces thetxcd_########regex correctly.- No missing validation paths or unhandled cases remain.
All required validators are in place; no further changes needed.
openmeter/ent/db/billinginvoicesplitlinegroup_create.go (3)
1-1: Generated code looks structurally correctThe file follows standard Ent patterns for entity creation. The implementation includes proper field setters, validation, edge management, and bulk operations support.
753-784: Correct handling of immutable fields in upsert operationsThe
UpdateNewValuesmethod properly ignores immutable fields (ID, Namespace, CreatedAt, Currency, FeatureKey, Price, and subscription-related IDs) during upsert operations, which aligns with the schema definition.
314-361: Comprehensive validation implementationThe validation logic correctly checks all required fields and applies custom validators for namespace, currency, tax_config, and price fields. Error messages are descriptive and follow consistent patterns.
openmeter/ent/db/billinginvoicesplitlinegroup_update.go (3)
21-185: Update builders correctly exclude immutable fieldsThe update implementation appropriately excludes setter methods for immutable fields (Currency, FeatureKey, Price, and subscription-related IDs), preventing modifications to fields that should remain constant after entity creation.
256-261: Proper automatic timestamp update handlingThe update operations correctly set the
UpdatedAtfield automatically when not explicitly provided, ensuring proper audit trail for entity modifications.Also applies to: 626-632
186-225: Well-implemented edge management for billing invoice linesThe update builders provide comprehensive edge management methods (Add, Remove, Clear) for the one-to-many relationship with BillingInvoiceLine entities, following standard Ent patterns.
Also applies to: 544-583
openmeter/ent/db/billinginvoiceline/where.go (8)
101-105: LGTM: Basic Currency predicate added.The new basic Currency predicate function follows the standard ent pattern and correctly handles the
currencyx.Codetype conversion to string.
152-160: LGTM: Basic predicates for InvoiceID and ParentLineID added.These basic equality predicates follow the standard ent pattern for string fields.
197-200: LGTM: Basic SplitLineGroupID predicate added.The new basic equality predicate for the split_line_group_id field follows the standard pattern for string fields.
552-634: LGTM: Comprehensive Currency predicates added.The full set of predicates for the Currency field is correctly implemented. The
currencyx.Codeto string conversion is consistently applied across all predicate types (EQ, NEQ, In, NotIn, comparison, string operations, etc.).
636-644: LGTM: TaxConfig null check predicates added.The IsNil/NotNil predicates for the tax_config field follow the standard ent pattern for nullable fields.
926-1004: LGTM: Extended PeriodStart and PeriodEnd predicates added.The comprehensive predicate sets for PeriodStart and PeriodEnd fields follow the standard ent pattern for time.Time fields, providing full comparison and filtering capabilities.
1711-1784: LGTM: Comprehensive SplitLineGroupID predicates added.The full predicate set for the new split_line_group_id field correctly implements all standard string field predicates including equality, comparison, string operations, and null checks. This enables rich querying capabilities for the new split line group relationship.
1884-1905: LGTM: SplitLineGroup edge predicates added.The edge predicates
HasSplitLineGroupandHasSplitLineGroupWithfollow the standard ent pattern for many-to-one relationships. This enables filtering invoice lines based on their association with split line groups and applying conditions on the related split line group entities.
2 participants
Overview
See description here: #2961
This patch only contains the schema changes to make the other PR a bit shorter.
Summary by CodeRabbit
New Features
Database Changes
Chores