Skip to content

Commit a61b3c5

Browse files
committed
Readme.md. Mention :map field type
1 parent 6bf3b66 commit a61b3c5

File tree

1 file changed

+2
-1
lines changed

1 file changed

+2
-1
lines changed

README.md

Lines changed: 2 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -121,7 +121,8 @@ These fields will not change an existing table: so specifying a new read_capacit
121121
You'll have to define all the fields on the model and the data type of each field. Every field on the object must be included here; if you miss any they'll be completely bypassed during DynamoDB's initialization and will not appear on the model objects.
122122

123123
By default, fields are assumed to be of type `:string`. Other built-in types are
124-
`:integer`, `:number`, `:set`, `:array`, `:datetime`, `date`, `:boolean`, `:raw` and `:serialized`.
124+
`:integer`, `:number`, `:set`, `:array`, `:map`, `:datetime`, `date`, `:boolean`, `:raw` and `:serialized`.
125+
`array` and `map` match List and Map DynamoDB types respectively.
125126
`raw` type means you can store Ruby Array, Hash, String and numbers.
126127
If built-in types do not suit you, you can use a custom field type represented by an arbitrary class, provided that the class supports a compatible serialization interface.
127128
The primary use case for using a custom field type is to represent your business logic with high-level types, while ensuring portability or backward-compatibility of the serialized representation.

0 commit comments

Comments
 (0)