Home
Help
Register
Log in

Search

 
   Active Threads  

You are here: Home > LLBLGen Pro > LLBLGen Pro Runtime Framework> mn: Relationships Help
 

Pages: 1
LLBLGen Pro Runtime Framework
mn: Relationships Help
Page:1/1 

  Print all messages in this thread  
Poster Message
CliffH
User



Location:

Joined on:
03-May-2006 14:27:07
Posted:
52 posts
# Posted on: 06-Aug-2006 16:31:09.  
Associating three entities in a m:n relationship, e.g., employee, department,
dept_employee, is straightforward enough. However, I'm stuck on ways to remove an association and delete the (dept_employee) db record.

When the records exist in the db there is no problem because the bridging entity
dept_employee can be referenced from each of the parent entities using a prefetch
path.

but ...how can I work with entities that are new and IDs that are 0.

Here's a scenario. Employees are entered, Departments are entered, the user
clicks on an employee and is presented with a list of departments and uses a
checkbox to assign the employee to the chosen department. If one is selected, create a
new dept_employee entity, assign the employee and department and save.

What can I do if they decide to change department BEFORE the data is saved. I can't find a
solution to de-referencing the first dept_employee entity and creating a new one.

In this scenario, an employee can work for at most one department.

In my 'real world' scenario I have Passenger and Service and a bridging entity ServicePassenger with two columns being the FKeys from both parent, which together form the PKey. In this scenario there can be any number of passengers assigned (and de-assigned) to (from) a service.

I can't for the life of me find a solution to this vexing problem. Any help appreciated.

  Top
sparmar2000
User



Location:
Aylesbury, UK
Joined on:
30-Nov-2003 14:50:22
Posted:
341 posts
# Posted on: 06-Aug-2006 16:45:02.  
Maybe I am missing the point, but when you say

Quote:
What can I do if they decide to change department BEFORE the data is saved. I can't find a
solution to de-referencing the first dept_employee entity and creating a new one.


is it not possible to delete the row is in question in the dept_employee table - I am assuming that you have by now saved the record - mentioned previously by you.

Or is it that you have not saved to the DB, you want to 'delete' the row whilst still in memory.


  Top
CliffH
User



Location:

Joined on:
03-May-2006 14:27:07
Posted:
52 posts
# Posted on: 06-Aug-2006 16:52:52.  
Yes, delete the row whilst still in memory. But as it is new - Service, Pasenger and ServicePassenger are all new - there is no way of uniquely referencing the in-memory record to be removed.

All I have are two fields in ServicePassenger, Service_ID and Passenge_ID, both of which of course get their values from their as yet unsaved parents, so all 0s and no way out.

I'm figuring that I just don't have enough information to do this.

I'll go with servicepassenger.ObjID, store that in table used as a datagrid datasource hidden column. If servicepassenger has an empty ObID and is checked in the grid then it needs creating, if it has an ObjID then this can be retrieved by looping through the entity collection. A copy of the table will tell me if it was checked before but now is unchecked, so remove it. If I need to remove it from the collection then no problem using above to retrieve it by ObjID and it's index.

I'm sure this will work OK.




  Top
sparmar2000
User



Location:
Aylesbury, UK
Joined on:
30-Nov-2003 14:50:22
Posted:
341 posts
# Posted on: 06-Aug-2006 19:33:18.  
CliffH

The way I have done this is some of my projects is some thing like this:

1. Get First Parent - Service
2. Get seceond Parent - Passenger

Display, accept users action indicating association between the two

User clicks 'Save'

3. 'New' the ServicePassenger entity and save.

This allows the user the flexibility of 'experimenting' and the code is simplified.

Methods such as (see documentation on GetDependingRelatedEntities, GetDependentRelatedEntities and SetRelatedEntity, UnSetRelatedEntity methods), could help, but leaving the creation of the entity until the last moment I feel would simply coding.

Just a suggestion Laugh



  Top
Jessynoo
Support Team



Location:
Lyon, France
Joined on:
19-Aug-2004 06:39:28
Posted:
296 posts
# Posted on: 07-Aug-2006 11:05:45.  
Hi

Quote:
In this scenario, an employee can work for at most one department.


That should have led you to adopting a simple fk without an intermediate table. You should avoid those extra tables when not needed because they are indeed quite painful to deal with.

Then I agree you should leave the creation of the entity to save to when you really want to do so.

Now, I'm not sure to understand why you can't unset your relation table entity.

if your department change, can't you do myRelatedEntity.Department = myNewDepartment?

I once thought the readonly nature of pkside related entity properties were a problem. But if you look at the generated code, you'll see that the events like those mentioned by sparmar are always fired and result in an entity sync.

For instance, the collections are all read only, but the ParentEntity property of the child entities from withing the collection are editable.

If you want to do a myCollec.Remove(MyChild), then MyChild.Parent = SomeOtherParent (replacement) / SomeJunkTempParent (deletion) should do the job
Jesse
LLBLGen Pro Support Team
 
Top
pilotboba
User



Location:

Joined on:
05-Aug-2005 21:31:38
Posted:
434 posts
# Posted on: 07-Aug-2006 21:19:54.  
Jessynoo wrote:

That should have led you to adopting a simple fk without an intermediate table. You should avoid those extra tables when not needed because they are indeed quite painful to deal with.


Actually, espesially in an HR app, using a table like this is common. The association table also have effective date and term date. This keeps a job history of the employee as is required in an HR system.

I have also seen this in financials apps in certain circumstances. Many times there is a difference between the business relationship and the physical data. Alot of times views are used to simplify these relationships.

BOb



  Top
Jessynoo
Support Team



Location:
Lyon, France
Joined on:
19-Aug-2004 06:39:28
Posted:
296 posts
# Posted on: 08-Aug-2006 11:43:07.  
Quote:
In this scenario, an employee can work for at most one department.

Quote:
This keeps a job history of the employee as is required in an HR system


Then I guess you filter on the dates to get the current department right?

Now, about what I said previously, did you find ways to unset a not saved yet relation?
Jesse
LLBLGen Pro Support Team
 
Top
Pages: 1  


Powered by HnD ©2002-2007 Solutions Design
HnD uses LLBLGen Pro

Version: 2.1.12172008 Final.