Re: Recommended method of using/getting to PK IDs

From: Holger Hoffstätte (holge..izards.de)
Date: Tue May 27 2003 - 16:26:45 EDT

  • Next message: John Poole: "RE: Recommended method of using/getting to PK IDs"

    "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