Adding UUID v4 type keys. #37

Closed
wants to merge 6 commits into
from

Projects

None yet

2 participants

Contributor

Hi Evan --

I have a use case where UUIDs and not serial integers are
required for the ID field throughout my DB. To facilitate this,
I've made a couple of changes to boss_db.git:

  • passing Options to the boss_db_adapter_mock and then to
    boss_db_mock_controller;
  • setting the IdCounter (the second piece of state data) in the
    mock_controller server to the atom "uuid" when the Option property
    "db_keytype" is set to "uuid";
  • generating a v4 UUID for unspecified Id fields;
  • changing the way ExistingId is parsed (to bypass tokenization)
    when the IdCounter state is set to "uuid".

Additionally, I've changed ChicagoBoss.git to add the property
"db_keytype" the Options sent to to boss_db:start/1. I'll submit a
pull request for that change and reference this one.

I've done preliminary testing with cb_admin and the scheme seems to be
working correctly for both {db_keytype, uuid} and an unspecified
db_keytype (i.e., it's backwards compatible). What I have not done
is:

  • tested relationships between models;
  • changed any of the external adapters (I have a need to update the
    pgsql adapter which seems straightforward, I haven't examined the
    others yet);
  • updated the documentation appropriately.

Before I went any further, I wanted to float the idea by you to see if
it's something you'd consider adding to the mainline and to double
check that the methodology is sound. Any advice is welcome!

Note that I'm using Travis Vachon's erlang-uuid library (BSD licensed
and I believe redistributable in this way) to generate the UUIDs.

Thanks for your consideration and for a really useful framework.

@kevinmontuori kevinmontuori referenced this pull request in ChicagoBoss/ChicagoBoss Sep 13, 2012
Closed

Adding UUID v4 type keys. #153

Contributor

Hi Kevin, thanks for the patch! I like the idea and how you are going about it, db_keytype works fine. I wonder though if people will want to configure this at a per-table level? What is your experience? Maybe people could override the setting in the model with

-module(my_model, [Id::uuid(), ...]).

or

-module(my_model, [Id::serial(), ...]).

kevinmontuori added some commits Sep 14, 2012
@kevinmontuori kevinmontuori added allowance for Id type information in model;
refactored record type validation to always validate id regardless of value or type
16b2a8f
@kevinmontuori kevinmontuori mock controller refactored to consider ::uuid() Id type dba7383
@kevinmontuori kevinmontuori fixed uuid keytype regression 8032697
@kevinmontuori kevinmontuori removed db_keytype property,
now relying on the ::uuid() type in the model spec.
7310041
@kevinmontuori kevinmontuori tweaked mock controller to not use uuid as an IdCounter anymore;
fixed up the news_controller to limit id splits to two parts, making uuids ok.
885228e
Contributor

Having reviewed Evan's comment about specifying keytype as part of the module/attributes definition I think that's a far better approach. I'm closing this pull request and will submit a different one based upon that scheme.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment