Adding UUID v4 type keys. #37

Closed
wants to merge 6 commits into
from

Conversation

Projects
None yet
2 participants
Contributor

bunnylushington commented Sep 13, 2012

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.

bunnylushington referenced this pull request in ChicagoBoss/ChicagoBoss Sep 13, 2012

Closed

Adding UUID v4 type keys. #153

Contributor

evanmiller commented Sep 13, 2012

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(), ...]).

bunnylushington added some commits Sep 14, 2012

@bunnylushington bunnylushington added allowance for Id type information in model;
refactored record type validation to always validate id regardless of value or type
16b2a8f
@bunnylushington bunnylushington mock controller refactored to consider ::uuid() Id type dba7383
@bunnylushington bunnylushington fixed uuid keytype regression 8032697
@bunnylushington bunnylushington removed db_keytype property,
now relying on the ::uuid() type in the model spec.
7310041
@bunnylushington bunnylushington 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

bunnylushington commented Sep 17, 2012

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