Data Mapper

[raduendv]

Data Mapper implementation #3294

[OrHayat]

im not aws worker or something but i kind of wanted to propuse similar thing. and i have done similar work at my company(resulted in different api because of some of the folowing things ill mention)

there are some really good ideas in this pr like table lifecycle hooks on the request to update/put and so on..

my main issuess with that pr is

1. u mixed new serializer code with tables abstraction so u did alot of duplicate work above existing dynamodb.attributevalue codebase. - you also kept alot of the inefficienes that it does
   when i say that i mean to compare to JSON v2 package - you check once what the type of the serialzied item is
   and then u get/build serialzer/de-seiarlizer for that type and call into it
   instead of dynamiclly checking each and every type that the value can be

2. you made tag struct even more bloated then previous version of serializer
   i would personally move some of those fields into schema defintion in the table constructor
   that because it make it wierd to denormlize stuff easily(you need to duplicate code)
   for example by moving non seralization stuff to the table defintion you can do

  type User struct {                           
      Name  string `dynamodbav:"name"`                                                                                 
      Email string `dynamodbav:"email"`                                                                                
  }                                                                                                                    
                                                                                                                       
  type Order struct {
      Total  int    `dynamodbav:"total"`
      Status string `dynamodbav:"status"`
  }

  // Clean composition — no duplicated fields
  type UserOrders struct {
      User
      Order
  }

and store struct each one at its own table - table struct define the schema /autoversion/any other stuff - not the serializer itself

3a) lack of transaction is pretty huge u can build generic wrapper on transactions(read/write ones)
if u want fully generic api each table append "step" to the transaction and at the end you have non generic execute call that does the transaction
3b)same to 3a but lack of batchGet/Batch write on multiple table instances

4. missing opportunity have way to validate the tables pk/sk
   aginst real table in some nice way(you have dynamodb api can compare schema to the existing table schema - this will allows checking of bugs at CI/start time of app instead of runtime and having it failed silently