"Merritt, Scott" wrote:
> What is the recommended way to access a fetched object's primary key? I
The (by me) recommended way is 'not at all'. I know that sounds overly
dogmatic, but bloody experience has taught me (and quite a few others that
I know) that using the primary key of an object in the business layer is
"almost" always wrong. Exposing the PK to the outer world and, as you plan
to, to customers as persistent bookmarks, completely robs you of any
possible ways of schema evolution and DB migration.
> thought the easiest way would be to just create an attribute and map it
> to the column in the table, but that broke the autogen of the IDs for my
That's by design, if I remember correctly. Exposing the PK means you take
care of it. I usually don't recommend that either since as soon as you
expose the PK people _will_ start to use and, more importantly, _abuse_ it
in horrible ways. Since current PK generation stategies are not as fully
developed as we would like to see them, it is still sometimes unavoidable.
The goal is to make any need for the PK completely avoidable.
Accessing primary keys is one, if not the main reason why database
applications are so notoriously expensive and hard to get right, let alone
to maintain in an orderly fashion.
> objects. I started poking around and found a getObjectId() method off
> fetched objects that sounded like it would do the trick. From that, I
> get the ObjectId object that I can call getIdSnapShot() which apparently
> returns a Map of all the PK attributes. Does it sound like this is the
> way I should be going about it, or would it be better to go down a
> different path?
ObjectId is exactly the intended way of getting hold of, well, the
object's id. :-)
Now that really happens to be just the primary key, but ideally you
shouldn't bother with the (usually single) PK key/value pair. You litter
your code with the name of an attribute that should be hidden and only
used by the mapping; you also make the assumption that, at that point, the
primary key has a certain structure. That might change, and then you'll
have to play catch-up in many places.
> I'm building a web app and want to pass around the IDs in URLs so I can
> easily reference records and when the user bookmarks the page, they get
> a bookmark to that record to come back to later.
A common thing, and good UI for a webapp. When I had to do this in
WebObjects and EOF, I always either:
a) introduced a surrogate attribute that was unique (kind of a public
second PK) or
b) encoded the serialized EOGlobalID (EOF's equivalent to ObjectId) as
Base64 String and passed that around instead. Not structure-preserving
either, but at least more 'safe' for public references since it creates
effectively unhackable URLs, and also protects you against co-workers who
think they need to break things by bypassing the design. This approach
might not be feasible if you need another system (DB storec procedure,
mainframe, PHP, whatever) to access the data via the given reference.
Again: try to use a surrogate, public reference.
good luck!
Holger
PS: Andrus: would it be handy to have a standard base64 ObjectId
encode/decode utility?
This archive was generated by hypermail 2.0.0 : Tue May 27 2003 - 16:26:12 EDT