I have the following tables:

• Document
• Mutation
• PeriodStats There is a one-to-many relation between document and mutation, and a one-to-many relation between PeriodeStats and Mutation. I need to process a collection of documents. I fetch the documents and the mutations for each document. I update the document, add some mutations and alter the state-field of some other mutations. So far, so good. But now i also need to update the PeriodStats table.

If i would fetch the periodeStats table for each mutation, i would end up fetching the same records over and over again. e.g: I fetch 200 documents, each having 10 mutations. That 2000 mutations are related to 15 periodStat records.

I am looking for a method to do this that is efficient, and -if possible- requires minimal coding effort as well.

Use prefetch path to fetch the graph, IF you want to work with a graph. The prefetch path will make sure you won't fetch an object more than once. Use a Context object to get unique objects, and re-use objects, to prevent editing an entity more than once.

Otis wrote:

Use prefetch path to fetch the graph, IF you want to work with a graph. The prefetch path will make sure you won't fetch an object more than once.

I also add a lot of new records, and as a result it might be neccessary to add some PeriodStats as well. How does a prefetch path help me there?

Otis wrote:

Use a Context object to get unique objects, and re-use objects, to prevent editing an entity more than once.

I will take a look at that.

wvnoort wrote:

Otis wrote:

Use prefetch path to fetch the graph, IF you want to work with a graph. The prefetch path will make sure you won't fetch an object more than once.

I also add a lot of new records, and as a result it might be neccessary to add some PeriodStats as well. How does a prefetch path help me there?

A prefetch path is only helping you with the fetching. When adding a new PeriodStat object, you can again use a Context object to keep just 1 entity instance in memory for a given PeriodStats entity.

Using the context is more complicated than i thought. I am now strugling with the new records.

From the LLBLGen documentation:

This means that new entities aren't directly added to the Context's internal object cache, as for example Identity columns won't have a value for the PK field until they're saved and the transaction has been committed. When an entity is saved and the transaction is committed (if any), the entity is added to the Context's cache if the entity is new.

The situation at hand is: I need to create a new record. I want to put it into the context because i will need to update it later in the process.

The documentation suggests it will not be added to the context until i save it and commit the transaction. But i don't want to commit the transaction untill i am completely done. Is there an alternative?

wvnoort wrote:

Using the context is more complicated than i thought. I am now strugling with the new records.

From the LLBLGen documentation:

This means that new entities aren't directly added to the Context's internal object cache, as for example Identity columns won't have a value for the PK field until they're saved and the transaction has been committed. When an entity is saved and the transaction is committed (if any), the entity is added to the Context's cache if the entity is new.

The situation at hand is: I need to create a new record. I want to put it into the context because i will need to update it later in the process.

The documentation suggests it will not be added to the context until i save it and commit the transaction. But i don't want to commit the transaction untill i am completely done. Is there an alternative?

New entities aren't added, as the PK can be sequenced which means all new entities have the same PK value, so the right one can't be found back.

I assume you want to use the Context because you have an 1:n relation and you start with the 'n' side, and thus have 1 entity to deal with for a lot of 'n's. ? What if you start from the other side?

Otis wrote:

I assume you want to use the Context because you have an 1:n relation and you start with the 'n' side, and thus have 1 entity to deal with for a lot of 'n's. ? What if you start from the other side?

Yes, I start with the 'n' side. Actually it's a 1:n:1 and I start with the first '1', so starting with the other '1' don't help that much.

I think this means I have to sort the 'n' entities, and fetch the second '1' at the sort break (the heading) and save at the footing.

wvnoort wrote:

Otis wrote:

I assume you want to use the Context because you have an 1:n relation and you start with the 'n' side, and thus have 1 entity to deal with for a lot of 'n's. ? What if you start from the other side?

Yes, I start with the 'n' side. Actually it's a 1:n:1 and I start with the first '1', so starting with the other '1' don't help that much.

I think this means I have to sort the 'n' entities, and fetch the second '1' at the sort break (the heading) and save at the footing.

You could try this: - create the associations between mutation and Periodstats like myMutation.PeriodStat = myPeriodStats; - Create a hashtable where you store the PeriodStats objects you've already edited. Do that by storing the ObjectID as key (and the object or null as value). This way, you can traverse from mutation to periodstat, and you can easily and fast check if you've already edited periodstat.

Could that work?

Otis wrote:

You could try this: - create the associations between mutation and Periodstats like myMutation.PeriodStat = myPeriodStats; - Create a hashtable where you store the PeriodStats objects you've already edited. Do that by storing the ObjectID as key (and the object or null as value). This way, you can traverse from mutation to periodstat, and you can easily and fast check if you've already edited periodstat.

Could that work?

Yes. After some restructuring my code works that way.