Grouper Developers Forum

[Tom Zeller <>]

> 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?

Yeah, isn't that what you meant ? Or were you thinking yyyymmddhhmmss.millis ? or ?

 

> 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?

Separate and/or optional. But we do want to be able to import/export, I would think.

 

>
> 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