"surrogate" keys and external data

25 views
Skip to first unread message

Tim Pigden

unread,
Apr 16, 2013, 2:10:47 PM4/16/13
to mapp...@googlegroups.com
I have a problem I'm not sure the best way to model and it doesn't seem to match your use cases.
I have a js client that expects an int id on the data.
The client will create new records and wants the int id back with the persisted record.
Subsequently an edit in the grid will send that record (or another) back with the the int id. I will then parse the passed in json
complete with an id field and will want to save the update.

Now if I use surrogateIntId I can't see how I create a record with an id from an external source.
If I use NaturalId I'm not sure the point at which I get the database to autogenerate the id for the new record.

This doesn't seem like an unusual use case - just one I've not had before.

What's the recommendation?

Tim

Konstantinos Kougios

unread,
Apr 16, 2013, 3:47:50 PM4/16/13
to mapp...@googlegroups.com, Tim Pigden
On 16/04/13 19:10, Tim Pigden wrote:
> I have a problem I'm not sure the best way to model and it doesn't
> seem to match your use cases.
> I have a js client that expects an int id on the data.
> The client will create new records and wants the int id back with the
> persisted record.
> Subsequently an edit in the grid will send that record (or another)
> back with the the int id. I will then parse the passed in json
> complete with an id field and will want to save the update.

So if I understand correctly you won't know what to do with the
"updated" id and how to update the user?

Seems like an entity with a SurrogateIntId (autogenerated) will do,i.e.
say you want to have a use case with a User domain class:

js save a new User => json data without id (or with a dummy id) => val
stored=mapperDao.insert(UserEntity,new User(name))

Now stored is a User with SurrogateIntId and you can send back the id to
the javascript. stored.id contains the autogenerated id.

for the update:

val u=mapperDao.select(UserEntity,id) (u.id contains the id) => send via
json => javascript render the edit user form =>

=> user submits => { user { name:"Kostas" , id:50 } } => val
updatedUser=mapperDao.merge(UserEntity,new User(name),id)

Note that merge does a select and then an update at the moment.

Is that what you need?

Cheers




>
> Now if I use surrogateIntId I can't see how I create a record with an
> id from an external source.
> If I use NaturalId I'm not sure the point at which I get the database
> to autogenerate the id for the new record.
>
> This doesn't seem like an unusual use case - just one I've not had before.
>
> What's the recommendation?
>
> Tim
> --
> You received this message because you are subscribed to the Google
> Groups "mapperdao" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to mapperdao+...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

samzil...@gmail.com

unread,
Apr 19, 2013, 1:43:15 AM4/19/13
to mapp...@googlegroups.com
You need a model that has an id in it, example:
case class User(id: Long = 0L, email: String, password: Option[String] = None....)

And an entity with a surrogate id (in this case Long) that overrides the id:

object UserEntity extends Entity[Long, SurrogateLongId, User]("users") {
  val id = key("id") autogenerated (_.id)
  val email = column("email") to (_.email)
  val password = column("password") option (_.password)
  ... more cols? ...

  def constructor(implicit m: ValuesMap) = new User(constructor with cols...)
    with Stored {
    override val id: Long = UserEntity.id
  }
...
}

this way you have a model with an id - so you can always access it and check what it is - but also get the db to create it for you by overriding it in the entity.

the client will send all the needed fields to the server, there a User will be created with that data, persisted, then you can return the id of the persisted data...

I don't understand at which point you need to accept an id from an external source.
The db is always creating the unique ids for your entity.
In the case you really want to have a "dummy" id until the entity is persisted, you have the default id=0L in the entity's constructor...
Reply all
Reply to author
Forward
0 new messages