Hi all
Actually, I would prefer a filter set on the entity that would apply for all
operations on entities of that type…
Something like:
The sample entity (base class for all security relevant classes):
@Filter(name="accessLevel", condition=":current > accessLevel")
public class SampleClass {
private int accessLevel;
...
}
The access snippet:
EntityManagerFactory emf =
Persistence.createEntityManagerFactory("Tutorial");
EntityManager em = emf.createEntityManager();
em.enableFilter(accessLevel, new FilterArgument("current",
user.getAccessLevel())) ;
- Any JPQL Statement implicitly ignores objects that matches the filter
- Loading of objects and associations also ignores them.
em.disableFilter(accessLevel);
Of course changing a filter would require to clear the cache…
The soft-delete problem can be formulated as �...@filter(name="deleted",
condition="deleted=1")”. For deleting an object I would still use just an
update statement. Or the better, JPA should support an �...@insteadofdelete”
callback…
Regards,
Lukas
Steven Eckert wrote:
>
> Hi Pinaki
>
> Thank you for your quick reply. I'd implement the soft delete with two
> distinct functionalities.
>
> The first would be to enhance the FilterDef. I'd add an inherit flag and a
> includeReference flag . E.g. @FilterDef(name = "isDeletedFilter",
> defaultCondition = "deleted = 0", inherit = "true", includeReference =
> "true"). This would allow me to define a filter on the base class (due to
> the inherit flag), which would be valid for all subclasses. The
> includeReference would indicate, thatloading a OneToMany inheritance, for
> the Many entities this filter is active.
>
> The second would be to add a BeforeDelete handler. This would be the same
> as the OnDelete but would return a boolean, if the entry should physically
> be deleted or not.
>
> The soft delete would be implemented by
> - Adding a FilterDef and defining a filter on the base class as described
> above with inherit = "true" and includeReference = "true". This would
> ensure, that any entities, marked as deleted would not be loaded. Either
> as Entity or as foreign key reference.
> - Creating a BeforeDelete handler, that "deletes" the Entity (by updating
> the Entry to be deleted and setting the deleted flag to true) and return
> false. This ensures the when a delete occurs, the entry is not physically
> deleted and it is marked as deleted.
>
> Please give me your view on this topic.
>
>
> Regards,
>
> Steven
>
>
> Pinaki Poddar wrote:
>>
>> Hi,
>>> is there any global Datafilter with OpenJPA available?
>>
>> This is an often requested feature, especially filter out 'softly
>> deleted' records. Also to filter multi-cardinality relations. But OpenJPA
>> does not (yet) have it.
>> Your requirements mention a more dynamic behavior. For example, in
>> some cases you want to access the softly deleted records, in some cases
>> you don't. Some filters are based on current user's security level. Few
>> of the inputs we will like to receive are
>>
>> a) what are the appropriate mechanics to describe the filter?
>> Class-level Annotations, Fetch Plan or a separate interface, query hints,
>> ....?
>> b) at what level such a filter should apply? Class, Field, both?
>> c) What is the syntax for the filter description?
>>
>> Let us know, with a concrete example how you will like to specify
>> the logical delete use case.
>>
>> Pinaki
>>
>
>
--
View this message in context:
http://n2.nabble.com/Global-%28session-based%29-data-filter-tp2269289p2389556.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.
