New Posts New Posts RSS Feed: Working with Composite Keys
  FAQ FAQ  Forum Search   Calendar   Register Register  Login Login

Working with Composite Keys
 Post Reply Post Reply
Author
  Share Topic Share Topic  Topic Search Topic Search  Topic Options Topic Options
Customer View Drop Down
Senior Member
Senior Member
Avatar
User Submitted Questions to Support

Joined: 30-May-2007
Location: United States
Posts: 260 		Post Options Post Options   Quote Customer Quote  Post ReplyReply Direct Link To This Post Topic: Working with Composite Keys
    Posted: 30-May-2007 at 4:52pm

The Developers Guide says:

“Most of the time an object’s key consists of a single identifier and so the words “key” and “identifier” are used interchangeably. Multipart keys are possible and sometimes necessary but we prefer single part keys.”

How do you accommodate those in DevForce?  For example, how would you do the equivalent of the following for Employee object with a composite key?

 

[DataObjectMethod(DataObjectMethodType.Select)]

    public BindableList<Employee> GetSelectedEmployee(string sort, Int64 id) {

      EntityQuery empQ = new EntityQuery(typeof(Employee), Employee.IdEntityColumn, EntityQueryOp.EQ, id);

      Employee emp = this.PersistenceManager.GetEntity<Employee>(empQ);

      BindableList<Employee> blist = new BindableList<Employee>();

      blist.Add(emp);

      CreateEmployeeBitMap(emp);

      return blist;

    }

Also, why do your prefer single-part keys?
Back to Top
IdeaBlade View Drop Down
Moderator Group
Moderator Group
Avatar

Joined: 30-May-2007
Location: United States
Posts: 353 		Post Options Post Options   Quote IdeaBlade Quote  Post ReplyReply Direct Link To This Post Posted: 30-May-2007 at 5:26pm

DevForce supports the use of composite keys, and we have many customers who use this strategy.  Furthermore, we never (or at least almost never) tell our customers that they need to redesign their database.

For our own work, we prefer single-part keys (when we have the option of choosing the key type) --  simply because they are more convenient to work with than composite keys. For that matter, we also prefer “artificial” keys – those with no meaningful connection to the other information in their record.  That avoids many problems that occur when factors external to the database force that other information to change.

To make your code work with a composite key, you would simply add additional clauses to the query to specify the value of the remaining column(s) that participate in the key.  For example, immediately following the statement where you instantiate the query, and before using that query in the GetEntity() method call, you could add a statement like the following:

      empQ.AddClause(Employee.IdPart2EntityColumn, EntityQueryOp.EQ, idPart2);
Back to Top
 Post Reply Post Reply

Forum Jump Forum Permissions View Drop Down