StrataFrame Forum » StrataFrame Application Framework - V1 » Issues » PK identification in Mapper

PK identification in Mapper

Daniel Essin — Thu, 15 Dec 2005 17:17:05 GMT

I have a 2 database tables defined as in erd.jpg. In the mapper (see jpg's) each table has only one field flagged with the key icon. I am confused.

RE: PK identification in Mapper

StrataFrame Team — Thu, 15 Dec 2005 17:17:05 GMT

When you configure your tables with a guid primary key, are you using a Char(32) data type and putting the guid in that, or are you using the UNIQUEIDENTIFIER data type and storing the guids there? Because if you're using the Char(32) type, you might consider changing them to the UNIQUEIDENTIFIER because it's half the size and optimized for guids. Also your field properties on the business objects would return a System.Guid rather than a string. Just a thought.

RE: PK identification in Mapper

StrataFrame Team — Thu, 15 Dec 2005 17:13:54 GMT

Not a problem :)

RE: PK identification in Mapper

Daniel Essin — Thu, 15 Dec 2005 15:50:18 GMT

I can do that. Most of my tables use a string guid as the key. There are only a few that have multi-part keys. Converting them will not be too big a deal.

Thanks.

RE: PK identification in Mapper

StrataFrame Team — Thu, 15 Dec 2005 08:27:29 GMT

I think your best bet is to add an ID column to your table as an integer or guid type. Set the primary key on it, and let it be a the index. Then, define a UNIQUE constraint on your combination of 3 columns. The INSERTs, UPDATEs and DELETEs will be faster with the single part primary key and you will still have the UNIQUE constraint on the current 3-part primary key setup.

RE: PK identification in Mapper

StrataFrame Team — Wed, 14 Dec 2005 23:37:13 GMT

StrataFrame is only plumbed to handle single-part primary keys. So, when you define the table in the database, and the Business Object Mapper checks the sysobjects table for the primary key, it will only pull the first column defined in the primary key. A great deal of functionality in StrataFrame would become infinitely more complex with complex primary keys (SeekToPrimaryKey, NavigateByPrimaryKey, parent-child relationships, etc.) A large portion of the latest update was aimed at abstracting the data access to facilitate easier changes and allow a StrataFrame developer to write their own data access, so StrataFrame could certainly be designed to support it.

RE: PK identification in Mapper

Daniel Essin — Wed, 14 Dec 2005 19:51:57 GMT

Also, if the relationships are not captured in the mapper, what keeps the apps in sync with the way the constraints are defined in the database?