Bjørn Erik Pedersen

I'm just "guessing out loud here", but I would suspect that a lot of time in the above is spent in serializing to JSON and that it isn't the write...

1) Not sure we want yet another method that does something slightly different. I would suggest that the loading of the associations be instructed via options to `Find`. 2) `storm:"ref(Group)"`...

Thinking about it a little, one of the plus sides of these IDs is that they can be set before persisted to DB, so if this is added we should...

>I think there should be a way to setup the incrementer that would be called by Storm everytime it needs a new ID. Yes, we should add some kind of...

>type IDProviderFunc func(last interface{}) interface{} What is the purpose of `last`? I thought this was either very stateful (`meta.Increment`) or very stateless (`ULID`, `UUID`...).

Also see https://github.com/segmentio/ksuid

OK, I managed to delete my last comment. In the above I see: - `Get` from the pool, but no `Put`. That should get about the same performance, no surprise...

But it doesn't look like this is possible -- the encoding part of Gob is also very much stateful -- it keeps track of what typeinfo has been sent etc....

> This is a great idea but i can't imagine how it would be used Me neither ... I will investigate further later, let us keep this issue open.

Seems the "statefulness of Gob" has been discussed: https://groups.google.com/forum/#!topic/golang-dev/Znc7ExcE1gw