What Do Detached and Assigncurrentcontext Meaning

What do detached and assignCurrentContext meaning?

You can read about them in the dispatch_block_flags_t manual:

DISPATCH_BLOCK_ASSIGN_CURRENT
Indicates that a dispatch block should
be assigned the execution context attributes that are current at the
time the block object is created. …

DISPATCH_BLOCK_BARRIER
Indicates that a dispatch block should act as a
barrier block when submitted to a DISPATCH_QUEUE_CONCURRENT queue. …

DISPATCH_BLOCK_DETACHED
Indicates that a dispatch block should execute
disassociated from current execution context attributes such as QoS
class, os_activity_t, and properties of the current IPC request, if
any. …

I’ve only copied the first sentence from each flag’s documentation. Click the link for more details.

In swift 3, when we create a dispatchWorkItem, what does DispatchWorkItemFlags parameter mean?

DispatchWorkItemFlags are an option set that configure the behavior of a DispatchWorkItem value, including its quality of service class and whether to create a barrier or spawn a new detached thread.

Type Properties:

1. static let assignCurrentContext: DispatchWorkItemFlags
2. static let barrier: DispatchWorkItemFlags
3. static let detached: DispatchWorkItemFlags
4. static let enforceQoS: DispatchWorkItemFlags
5. static let inheritQoS: DispatchWorkItemFlags
6. static let noQoS: DispatchWorkItemFlags

Attaching and detaching entities from context correctly in EF4.1

IEntityWithKey is interface for other types of entities. It is for "big" entities. For example EntityObject implement this interface. These entities are not considered as POCO and are not supported by DbContext API.

If you want to use IEntityWithKey your classes must implement it - it is not something that would happen automatically.

Correct attaching with DbContext API should be:

dbContext.Set(typeof(entity)).Attach(entity); 

and this should hopefully also work:

dbContext.Entry(entity).State = EntityState.Unchanged;

Correct detaching with DbContext API should be:

dbContext.Entry(entity).State = EntityState.Detached;

Also it is better to you generic methods instead of object.

What are detached, persistent and transient objects in hibernate?

A new instance of a persistent class which is not associated with a Session, has no representation in the database and no identifier value is considered transient by Hibernate:

Person person = new Person();
person.setName("Foobar");
// person is in a transient state

A persistent instance has a representation in the database, an identifier value and is associated with a Session. You can make a transient instance persistent by associating it with a Session:

Long id = (Long) session.save(person);
// person is now in a persistent state

Now, if we close the Hibernate Session, the persistent instance will become a detached instance: it isn't attached to a Session anymore (but can still be modified and reattached to a new Session later though).

All this is clearly explained in the whole Chapter 10. Working with objects of the Hibernate documentation that I'm only paraphrasing above. Definitely, a must-read.

Entity Framework in detached mode with MVC application

To your concrete question: The entities are generated by a T4 template and it should be possible to modify this template (which is in text format) to generate the entities in a way you want to shape them.

But I have a few remarks about your concept:

• In a web application data are usually changed by a user in a browser. To have a definite knowledge what really has been changed you need to track the changes in the browser (probably by some Javascript that sets flags in the data (a ViewModel for example) when a user edits a text box for instance).

  If you don't track the changes in the browser what happens? The data get posted back to the server and you don't know at the server side (with MVC in a controller) which property has been changed. So, your only chance is to map all properties that has been posted back to your EntityClass and every property will be marked as Modified, no matter if the user really did a change or not. When you later call SaveChanges EF will write an UPDATE statement that involves all those properties and you have an unnecessary overhead that you you want to avoid.

• So, what did you win by setting individual properties instead of setting the whole entity's state to Modified? In both cases you have marked all properties as Modified. Exceptions are partial changes of an entity, for example: You have a Customer entity that has a Name and City property and a view that only allows to edit the Name but not the City and a corresponding ViewModel that only contains a Name property. In this case your procedure would only mark the Name property of the Customer entity as Modified but not the City. You might save here a little bit because you don't save the City property value to the database. But you still save the Name even if it didn't change.

• If you use solution 1 (ApplyCurrentValues) you have to load the entity first from the database, yes, but it would only mark the properties as Modified that really changed compared to their values in the database. If the user didn't change anything no UPDATE would be written at all.

• Keep in mind that you are only at the beginning to implement your concept. There are other changes to the data that can happen in the browser than only scalar property changes, namely relationship changes. For example a user changes the relationship from an Order to a Customer or you have a view that has an Order and a collection of OrderItems and the user cannot only edit the Order header but also edit the OrderItems and remove and add new OrderItems. How do you want to recognize when the data come back from the browser to the server which collection item has been added and which has been removed - unless you track all those changes in the browser and send tracking information back to the server in addition to the actual data or unless you reload the Order and OrderItems from the database and merge the changes into the original entities from the database?

Personally I would vote for option 1 for these reasons:

• You can use real POCOs that don't carry additional tracking information. (BTW: I have some doubt if you aren't reinventing the wheel by implementing your own tracking that EF change tracking proxies provide out of the box.)

• You don't need to track changes in the browser which can become quite complex and will require Javascript in every Edit view to write change flags into hidden form fields or something.

• You can use standard features of EF without having to implement your own tracking.

• You are required to load entities from the database when you want to update an entity, that's true. But is this the real performance bottleneck in a web application where data have to run through the wire back and forth (and reflection (which isn't really known as to be fast) is involved by the model binder)? I have nothing said if your database is remote from the web server and connected by a 9600 baud modem. But otherwise, your plan is not only premature optimization, it is kind of premature architecture. You are starting to build a potentially complex architecture based on "it could be slow" to solve a performance problem that you actually don't know of whether it really exists.

How do I detach objects in Entity Framework Code First?

If you want to detach existing object follow @Slauma's advice. If you want to load objects without tracking changes use:

var data = context.MyEntities.AsNoTracking().Where(...).ToList();

As mentioned in comment this will not completely detach entities. They are still attached and lazy loading works but entities are not tracked. This should be used for example if you want to load entity only to read data and you don't plan to modify them.

---

Related Topics