So at the moment, licensing only has the capability to attach to users.

I think there might be a case for changing the schema, namely:
1. 'uid' (user id) => 'eid' (entity id)
2. adding a new column 'entity_type' (node, order, user etc..)

I think I've seen something like this in userpoints module (http://drupal.org/project/userpoints) and it seemed to work pretty well.

CommentFileSizeAuthor
#2 license-643492-option1.png5.95 KBnicksanta
#2 license-643492-option2.png5.22 KBnicksanta
#2 license-643492-option3.png7.01 KBnicksanta

Comments

mradcliffe’s picture

mradcliffe
he/him
Primary language English
commented

I know that in regards to ubercart it's possible to connect license keys to an order id and a sku. So as to differentiate between licenses purchased on different orders. Thinking linearly you could have eid and type, and then a secondary eid and type. However this seems kind of ugly.

That said, sku or node could be the type, and a sub module could implement another table with id, eid, and order_id (at least for ubercart). Ugly, but a different kind of ugly.

nicksanta’s picture

nicksanta commented
StatusFileSize
new Option 37.01 KB
new Option 25.22 KB
new Option 15.95 KB

I've had a think about some of the options, and made a few diagrams - just so we're clear on what we're talking about.

The use case I was designing these options around was linking a license key to an ubercart order.

Option 1:
Schema is flexible to developer's needs

  • entity_type stores the table name for the join
  • eid stores the primary key to join on

Option 2:
Schema remains like it is currently, and the plugin module would have a table similar to this:

  • lid licensing_key primary key
  • oid uc_orders primary key

Option 3:
Similar to option 1, but has option for an extra join on that table.

  • pri_type is the primary table that should be joined (This would normally be the users table)
  • pri_id primary key for primary join
  • sec_type secondary table to be joined (uc_orders in this case)
  • sec_id secondary primary key

I honestly don't think that option 3 is a good way to move forward. It seems more like a tack-on solution that will only fulfill a few use cases.

Option 2 would be the easiest for us, as there is no schema / API changes at all. It would be up to the plugin module to provide those relationships.

Option 1 would be really nice from a flexibility point of view, and is where i would like the project to go. My main concern is it seems like prematurely over-flexibilizing the module, and making more work for us before we can get a solid release out.

Your thoughts?

nicksanta’s picture

nicksanta commented
Priority: Normal » Minor
Status: Active » Postponed

i think this is something worth coming back to for a 2.x branch or something.

grasmash’s picture

grasmash commented
Issue summary: View changes
Status: Postponed » Closed (won't fix)

The 6.x is no longer supported. Closing issue.