Support for custom params

[seizmo]

We use a multi-database based multi-tenant model in our app. This is not supported by the current gid format. A job scheduler has no way of finding out if "gid://MultiTenantApp/User/1" references the user in the database "tenant_1" or "tenant_2".

Some way to include the database name or tenant id would be very useful. Alternatively some way to easily add custom fields to gid would certainly be helpful.

[jeremy]

I hear you. All the ingredients for this are coming together, if you care to combine & bake:

1. register a custom locator for your app: Allow apps to hook in their own locator #7
2. implement in terms of a GlobalID::URI: Specialize our URI class rather than leaning on Ruby's URI::Generic as a URL #6
3. support your GlobalID params using GlobalID::URI query params: needs work! 😁

[jeremy]

❤️

On Wednesday, October 8, 2014, Kasper Timm Hansen [email protected]
wrote:

Closed #39 #39 via #44
#44.

—
Reply to this email directly or view it on GitHub
#39 (comment).

[jhubert]

@jeremy I'm curious about your opinion on "app" when it comes to the concept of a GlobalID and multi-database tenancy setups.

If the GID is a hierarchy, it seems like it's descending in specificity from App, to Model, to ID, to params.

If you're in a multi-tenant setup that uses different databases (or, like in our case, different schemas) then ids for objects can increment independently as though there in entirely different apps.

Thus, User.find(1) would return different records based on the current customer.

Using params support for tenants, the gids would look like this:

gid://MyApp/User/1?tenant=customer1
gid://MyApp/User/1?tenant=customer2

But, I've been playing with that for a little while and it feels out of place in the specificity. The tenant param feels to me like metadata, when it's actually core to the context of the object. You couldn't switch over to a different customer and find the object with the other customer's gid. In the hierarchy, it might better be placed between App and Model, like App -> Tenant -> Model -> ID.

Given the current structure of GlobalID, would it make sense to have one app per tenant, like this:

gid://MyApp-customer1/User/1
gid://MyApp-customer2/User/1

Do you see any issues with that? Am I thinking about GlobalIDs wrong?

[jeremy]

@jhubert, recommend you check out custom locator support

• Use compound IDs that combine the tenant and model ID
• Register a locator for your app that splits the compound ID and looks up the tenant and model separately