Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Subscriptions Internal APIs #1732

Open
wants to merge 14 commits into
base: main
Choose a base branch
from
Open

Subscriptions Internal APIs #1732

wants to merge 14 commits into from

Conversation

GAlexIHU
Copy link
Contributor

@GAlexIHU GAlexIHU commented Oct 21, 2024

Overview

Includes internal APIs for subscription Management

  1. DB Entities
  • Subscription + SubscriptionPatch (with value type normalized)
  • Price
  • SubscriptionEntitlement
  1. Interfaces
  • Subscription Package Connector with
    • Create
    • Get
    • Expand
    • Edit
    • Cancel (no-op / panics)
  • "Patch" Commands for (name TBD) to be used with Create & Edit
    • AddItem
    • RemoveItem
    • AddPhase
    • RemovePhase
    • ExtendPhase
  • SubscriptionXSpec & SubscriptionXView interfaces
    • define create specifications and defacto state for Subscriptions & its subresources
  1. Misc
  • Testutils for Subscriptions
  • Entitlement Annotations <= probably wrong implementation, annotation based Access Control checks for entitlements

TODO

  • Documentation
  • Self Review

@GAlexIHU GAlexIHU force-pushed the feat/subscriptions branch 2 times, most recently from b3e0052 to e3fb3f4 Compare November 3, 2024 16:16
@GAlexIHU GAlexIHU changed the title Subscriptions P1 Subscriptions Internal APIs Nov 3, 2024
@@ -0,0 +1,19 @@
package annotations
Copy link
Contributor Author

Choose a reason for hiding this comment

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

This'll probably need quite a bit of changing...

The idea is, that Metadata Annotations could be used to store & pass info external to the current domain, e.g. store on an Entitlement that it belongs to a Subscription, while Entitlements in general might not have anything to do with Subscriptions...

Then, in the entitlementdriver we could check / use these annotations (in this case for disabling modifying&deleting entitlements that belong to subscriptions).

IMO the way it currently is is ugly and mostly nonsensical, at least in part its here as a placeholder, any inputs are welcome

@GAlexIHU GAlexIHU added kind/feature New feature or request release-note/feature Release note: Exciting New Features area/entitlements area/product-catalog labels Nov 3, 2024
@GAlexIHU GAlexIHU marked this pull request as ready for review November 3, 2024 16:46
"github.com/openmeterio/openmeter/pkg/framework/entutils"
)

type SubscriptionPatch struct {
Copy link
Contributor

Choose a reason for hiding this comment

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

nit: SubscriptionPlanOverride rhymes better to me

func (SubscriptionPatch) Fields() []ent.Field {
return []ent.Field{
field.String("subscription_id").NotEmpty().Immutable(),
field.Time("applied_at").Immutable(),
Copy link
Contributor

Choose a reason for hiding this comment

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

is applied_at necessary if we have created_at? Can these differ?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes. appliedAt is programmatic time, it's kept constant through the entire use case prior creating the record and when reading the record. In practice, appliedAt will be the exact same for those in the same batch, and probably some ms / ns before createdAt

field.String("subscription_id").NotEmpty().Immutable(),
field.Time("applied_at").Immutable(),
field.Int("batch_index").Immutable(),
field.String("operation").NotEmpty().Immutable(),
Copy link
Contributor

Choose a reason for hiding this comment

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

should this be a type of Go enum like?
field.String("type").GoType(appentitybase.AppType("")).Immutable(),

field.Bool("create_entitlement_is_soft_limit").Optional().Nillable().Immutable(),
field.Bool("create_entitlement_preserve_overage_at_reset").Optional().Nillable().Immutable(),
field.String("create_entitlement_usage_period_iso_duration").Optional().Nillable().Immutable(),
field.JSON("create_entitlement_config", []byte{}).SchemaType(map[string]string{
Copy link
Contributor

Choose a reason for hiding this comment

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

can we normalize this?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

This is the config of static entitlements, it cannot be normalized.

openmeter/ent/schema/subscription_patch.go Outdated Show resolved Hide resolved
openmeter/subscription/adapter/mapping.go Outdated Show resolved Hide resolved
openmeter/subscription/adapter/mapping.go Outdated Show resolved Hide resolved
return def, err
}
} else {
return def, &models.GenericUserError{Message: "customer already has a subscription"}
Copy link
Contributor

Choose a reason for hiding this comment

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

should this be a specific error?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

could be a Conflict instead of a BadRequest

@@ -0,0 +1,223 @@
package subscriptionentitlement
Copy link
Contributor

@hekike hekike Nov 4, 2024

Choose a reason for hiding this comment

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

I thought we moved to adapter and serviceinsead of repository.

index.Fields("namespace", "id"),
index.Fields("namespace", "entitlement_id"),
index.Fields("namespace", "subscription_id"),
index.Fields("namespace", "subscription_id", "subscription_phase_key", "subscription_item_key"),
Copy link
Contributor

Choose a reason for hiding this comment

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

if I'm not mistaken, PG can use partial indexes and may above not require.
But I'm fine optimizing indexes later.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I'm not sure what you mean here. I think "Partial Index" officially refers to indexes with where clauses pretty much. If you mean why all the prefixing and not just have separate indexes, it can use multiple indexes

I didn't put too much thought into this, just added the exact indexes for the queries that will be run. I don't have a preference here at this point.

Copy link
Contributor

@tothandras tothandras left a comment

Choose a reason for hiding this comment

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

Discuss patch db before merging @hekike

feat: subscription creation wireframing

refactor: move subscriptions out of productcatalog

refactor: fresh start

feat(subs): define interfaces and subpackages
feat: implement patch serialization

feat: db structure for patches
fix: date use in subscription patches

chore: uncomment methods

fix: fix rebase issues
feat: add entitlement annotations

feat: write patch saving

feat: subscriptionView

feat: write db schema for patches

feat(subs): write entity mappings for repository
feat: implement price

test: write command and query builders

test: subscription creation without customizations

test(subs): test creation with customizations
feat: test editing and fix rebase errors
"github.com/openmeterio/openmeter/pkg/framework/entutils"
)

type Price struct {
Copy link
Contributor

Choose a reason for hiding this comment

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

Prefix please to SubscriptionPrice

@@ -0,0 +1,73 @@
package subscription
Copy link
Contributor

Choose a reason for hiding this comment

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

@@ -0,0 +1,388 @@
package subscription
Copy link
Contributor

Choose a reason for hiding this comment

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

@@ -0,0 +1,216 @@
package schema
Copy link
Contributor

@hekike hekike Nov 8, 2024

Choose a reason for hiding this comment

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

we discussed internally to apply patch at write time instead of read time and store final state in db

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/entitlements area/product-catalog kind/feature New feature or request release-note/feature Release note: Exciting New Features
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants