Markiemac wrote:
Walaa wrote:
Please refer to LLBLGen Pro documentation:
"Using the generated code -> SelfServicing/Adapter -> Using the entity collection classes" check the section "Entity retrieval into an entity collection object -> Using a related entity""
Had a look and it would appear that using the entity collection classes may be too costly, as I only need to know if there is an entry in any child table related to its parent.
You can always use a Scalar query to fetch a PK value and if it's null, it's not there, which answers the question if the related entity is there or not
The 'using a related entity' seems a good bet, but with the order being on the many side of the order/Customer relationship, in the example given, I don't know if the following is possible.
Division has one or more Sections.
A Section is part of one Division only.
Division has one or more Employees.
An Employee belongs to one Division only.
Dim Division As New DivisionEntity(10)
Dim adapter As New DataAccessAdapter(True)
adapter.FetchEntity(Division)
Division.Section = CType(adapter.FetchNewEntity(New SectionEntityFactory(), _
Division.GetRelationInfoSection()), SectionEntity)
Division.Employee = CType(adapter.FetchNewEntity(New EmployeeEntityFactory(), _
Division.GetRelationInfoEmployee()), EmployeeEntity)
adapter.CloseConnection()
Given that Division is on the 1 side of the relationship, can you see any problem with this?
Would I just get the first Section or Employee whose FK matched the Division?
I wouldn't do it this way. You already know the PK, '10', so you can use that in a filter to execute a direct delete on Section and Employee by using adapter.DeleteEntitiesDirectly(). This will execute a DELETE FROM .. WHERE ...
and the WHERE is thus of course your specified filter, thus filtering on DivisionID = 10 (or whatever fk field in section and employee points to division)
But since LLBLGen knows about the relationships, is there any functionality within LLBLGen to retrieve related information if its just given the parent details. That would mean not having to explicitly specify each child table.
Thanks
Yes you have. The reason is that LLBLGen Pro doesn't 'assume' something for you, you've to tell it what to do (to a certain point of course
). This gives the biggest flexibility and also the biggest feature set. The thing with relations is that they're hard to specify, as they don't have a unique number or something, they have a start and end entity, and also PK and FK fields. That can be a whole set of values, and how to make a unique key out of that? that's pretty complex, if not impossible. So LLBLGen Pro offers you the relations in code, like CustomerEntity.Relations.OrderEntityUsing... but you can't get a list of relations and then traverse them, because how will you know you found the relation you want?
I understand that it in your case means that you have to know all entities which have an FK to division / relation with division. But such information is inevitable anyway for writing a good db consuming application.