I have an ActiveRecord object that I need to be able to uniquely
identify before I actually save the object (I may not end up saving
the object based on conditions). This is because I want to use the ID
in another context (a file name in the filesystem).
Depending on conditions, I may or may not need to do a lot of stuff
between the time that I generate the object ID and actually make the
decision to save the object. I am toying with the idea of using an ID
generator for this object.
I wanted to get some input on using an “external to the DB” generator to
create my unique ids for insertion into the DB.
Am I overthinking this? Should I just do the insert as soon as possible
to have the DB generate my ID, use the ID as I need to, and then either
delete that record (or rollback a transaction) later if it turns out
that the record shouldn’t be saved after all?
Am I overthinking this? Should I just do the insert as soon as possible
to have the DB generate my ID, use the ID as I need to, and then either
delete that record (or rollback a transaction) later if it turns out
that the record shouldn’t be saved after all?
Yes, and no. I generally recommend not tying anything like this to
the primary key of a record. It’s much better to create an extra
column (VARCHAR of appropriate size) and use that as the file key. It
will still be saved with the record and you can still let Rails do
what it wants and maintain full control of the “external” stuff (file
names, etc).
I would recommend maybe a randomized MD5 hash system or such (similar
to the algorighm Rails uses to make sessions). UserID (or something)
Now (DateTime) + Random Number run through the MD5 hashing method to
generate a string you can use for the file name and data column. Your
ActiveRecord model subclass will happily work with the data and save /
retrieve it from the database. It also gives you an almost gauranteed
unique value (you can always run a search of the database and
regenerate if it’s not unique–if you’re paranoid)
Am I overthinking this? Should I just do the insert as soon as possible
to have the DB generate my ID, use the ID as I need to, and then either
delete that record (or rollback a transaction) later if it turns out
that the record shouldn’t be saved after all?
Yes, and no. I generally recommend not tying anything like this to
the primary key of a record. It’s much better to create an extra
column (VARCHAR of appropriate size) and use that as the file key. It
will still be saved with the record and you can still let Rails do
what it wants and maintain full control of the “external” stuff (file
names, etc).
I would recommend maybe a randomized MD5 hash system or such (similar
to the algorighm Rails uses to make sessions). UserID (or something)
Now (DateTime) + Random Number run through the MD5 hashing method to
generate a string you can use for the file name and data column. Your
ActiveRecord model subclass will happily work with the data and save /
retrieve it from the database. It also gives you an almost gauranteed
unique value (you can always run a search of the database and
regenerate if it’s not unique–if you’re paranoid)
-Curtis
Curtis,
I agree. Thanks for the advice. I ended up using user_id +
Time.now.to_f.to_s (with the fractional seconds I’m pretty confident
that the identifier will be unique).
the primary key of a record. It’s much better to create an extra
generate a string you can use for the file name and data column.
Curtis,
I agree. Thanks for the advice. I ended up using user_id +
Time.now.to_f.to_s (with the fractional seconds I’m pretty confident
that the identifier will be unique).
Take a look at the “uuid” gem. It will generate unique numbers on a
system and is already packaged up as a gem.