Grouper Developers Forum

[Chris Hyzer <>]

> It might be beneficial to take advantage of database-specific types
> for timestamp storage (e.g. searching). However, the xml format used
> by xmlimport/export should be
> database agnostic to allow someone to move grouper across databases.
> Would it then make sense to default to epoch millis unless some other
> use case appears ?

This means an integer in db for number of millis since 1970?


> 
> As you say, since multiple events may occur at exactly the same time,
> timestamp alone may not preserve order in all cases, hence the need
> for a db sequence. Can you say more about the challenges of
> importing/exporting a db sequence ? (it could just be an int that
> wraps, right ?)

For oracle, just need to make sure to update the current sequence val after 
an import so you don't have collisions... not sure about mysql/postgres...

Are audit records going to be exported with all the other data, or will that 
be a separate file?  I think it could be a lot of data so maybe we should do 
this in a separate file.  Thoughts?

Chris



> 
> On Feb 9, 2009, at 10:04 AM, Chris Hyzer 
> <>
>  wrote:
> 
> > I had hoped to start using timestamp db types instead of number of
> > millis... but on mysql it only seems to be to the precision of
> > seconds, not millis... also, for user audit records, I think being
> > able to order them is nice to have, but I don't know how to do it.
> > Even if we have millis, there could be two with the same millis, in
> > which case we are back to if we need a DB sequence or mysql auto
> > increment.  These are annoying for import/export reasons.
> >
> > Anyways, should we go back to using an integer with number of millis
> > in it?
> > Also, should we look into auto-increment in db's for log ordering?
> >
> > Thanks,
> > Chris