evanmiller/boss_db — pull request #38 by kevinmontuori (2012-09-20 15:59:12+00:00)
Title: Explicit keytype 2

Evan --

Here's a second attempt at adding an explicit Id::uuid type. There
are no changes required to ChicagoBoss.git. In general, there were
only a few changes required to update the mock and pgsql adapters:

- boss_record_compiler required a new process_tokens clause to
capture the ::uuid(). (I have a question about this: it appears
that the clause on line 36 will never match:

process_tokens([{'-',N}=T1,{atom,N,module}=T2, ...]);

Unless there's something I'm missing, N should be different in
tuple one and tuple two.)

- I opted to provide the UUID and not require the DB to supply it
(something Postgres will do with the appropriate plugin compiled
and loaded). As a result save_record/2 now calls
maybe_populate_id_value/1 which, seeing it's a uuid type, does
what you'd expect.

- build_insert_query/1 was updated to handle the case where the ID
supplied is a list. (As an aside, I couldn't figure out when the
stanza:

({id, V}, {Attrs, Vals}) when is_integer(V) -> ...

would be ever be called. It appears that build_update_query/1 is
called from save_record/2 when an ID is supplied.)

- integer_to_list/1 called on ID values has been replaced with a
call to id_value_to_string/1. I named it that to make the
intention clear, obviously id_value_to_list would be okay.

- Where it made sense, I updated re:split/3 calls to include the
option {parts, 2}. Likewise, some string:tokens/2 calls have been
replaced with re:split/3. I don't have great profiling
information to see how this changes performance.

- validate_record_types/1 now always validates the 'id' attribute.

- keytype/1 was added to boss_record_lib and exported. Either a
record or the type can be passed. Had to have something like that
that worked with types so that infer_type_from_id/1 (called from
find/2) would work correctly.

I hacked up a little integration test to be sure that things worked
the way I expected:

https://github.com/kevinmontuori/cb-keytest

All the tests succeed with the modified pgsql adapter; however, the
relational tests fail with the mock adapter. I'm not really sure what
the expected behavior there should be.

Thanks again for your time. I like CB quite a bit and it's now
solving a real business problem that we have. Some of the record
compiler code was a real eye-opener ... really nice work. Please let
me know what questions you might have.