We are using Devexpress XtraGrid together with Openaccess
- All persistent items have a property IsRemoved
- If the property is set, it should no longer be displayed in an XtraGrid - but it should also not be removed from database (simple do not delete strategy, objects could be recreated later)
- As IsRemoved Property should not be shown to customer, IsRemoved Property is not visible for XtraGrid
Can Openacces be told somehow to not keep filtered items in objectview.list, but also do not delete them? Like an output filter ?
7 Answers, 1 is accepted
As far as I understand the scenario you implement, you need to retrieve from the database only those objects that are not marked as removed.
If that is indeed the case, you can achieve the necessary result thanks to the OQLStatement property of ObjectProvider. Let's assume that the name of the class is DomainClass, the backend is SQL Server and the IsRemoved property of the class is of type Boolean. Than the filtering statement would be:
I hope that works for you. If my assumption is not correct or if you have additional questions, do not hesitate to get back to us.
All the best,
the Telerik team
I think that is not the problem.
What I mean is: I already have the data in a Grid. Now I want to set the IsRemoved property and "remove" the data from the resultset, but not from database.
Do you propose to in your answer to always fetch a complete new objectscope with filtered objects in this case? Would that not be to much load?
What I wanted to do is only remove the item from objectscope which is filtered to have less workload (but to remove it in a manner to not delete it from db)
Maybe a bit more detail: waht i mean is somethign like
will show that filters are not supported
When you set the IsRemoved property on the object you can call objectView.Remove(objToHideInGrid). You also need to set the PersistenceBehavior = none or markForAdd. So when you call objectView.Remove the object will only be removed from the objectView (and hence from the grid) but it will not be removed from the database.
In another related thread you replied that changing the PersistenceBehavior to 'None' or 'markForAdd' will still remove the object from the database. Did you actually observer this ? I tried it in a sample and just calling Remove and Save on the objectView does not delete the objects from the database.
the Telerik team
the problem I wanted to describe with objectView.Remove is that it does not solve 2 parts of the problem:
1. It should still be accessable, but normally not visible in ObjectView, so that a user can decide to show the "removed" item and "unremove" it. Like you are having a paperbin and just set a flag to see the removed items. Or use Delte, then an undo. And so on...
2. (i think the point with the misunderstanding)
If we do objectview.remove we quite often got a red cross and a NoSuchObjectException. If we only rmeoved it with objectview.List.Remove we didn't have the problem, but the List.remove was to slow (both needed to be done on UI thread (because of grid - only Begin(Data)Invoke... hasn't help)), so it blocked literally the visible part of the programm for 20 seconds.
So if the Remove is done, It still seems to be deleted from objectview, and it can no longer access it.At this point the original red cross problem reoccurs.
I don't know if i just cannot describe the problem accurately in english.
I was able to reproduce the behavior on objectView.List.Remove. Calling Remove on the objectView.List and not directly on the objectView causes the gridview to be out of sync with the underlying contents. The Windows Forms DataGridView then throws error while trying to repaint the deleted row. I would like to investigate further to confirm this but it probably is not ok to call objectView.List.Remove.
I will get back to you regarding the cause of the slow performance.
You said you get a red cross if you call objectView.Remove. Is this because the object has been deleted in another form in the meantime; maybe by another scope instance? If this is the case you would need to handle this in your application, so that you refresh the data in all scopes whenever 1 scope deletes an object.
- Xtragrid which deletes it
- All registered objectviews for datatype (we register the objectviews so that a remove can be called for other objetctscopes)
- Other possible XtraGrids which access data of same type
And with step 3 the problem occurs that sometimes an object seems to get accessed which should no longer be available.
This could maybe be some sort of Race condition. It normally happens if alot of data is deleted. Therefore to test it additional locks for the delete of objects which are synchronized to another pc was included, but that did not solve the problem.
I'm still wondering:
You have written that
objectView.List.Remove ... "Windows Forms DataGridView then throws error while trying to repaint the deleted row"
objectView.List.Remove I do not have the problem that the XtraGrid stalls, only with objectView.Remove
objectView.List.Remove looked like a public available method (no voodoo or reflection to call it)
ATM we use the intermediate solution with the copy.
ObjectView.List.Remove and ObjectView.Remove both remove the object from the same underlying list. The only difference is that 'ObjectView.Remove' additionally tries to remove it from the underlying scope also.
'ObjectView.List.Remove' causes the grid to be out of sync with the underlying list. This seems to be a bug but since there is an alternative to this (calling ObjectView.Remove) the fix is not scheduled yet.
I would suggest that you replace the ObjectView instances with standard List<T> and when you delete an object in 1 grid you can simply remove the object from other lists that are bound to other grids. The object will still be tracked by the scope but just not visible in the grid.