Discard revision in Hibernate Envers - hibernate-envers

I don't need to save revision in some cases for entity, but how to handle this way? I want to just skip creation of revision, already reviewed source codes, no chance.
If u try to make DB changes in custom EnversPostInsertEventListenerImpl, for example, make calls in same transaction like that (in onPostInsert):
PersistedProperty property = dao.findClass(PersistedProperty.class, "where propertyTemplate.id = ? and fileEntry.id = ?",
propertyTemplate.getId(), f.getId());
String v = convertObject2String(propertyTemplate, value);
if (property == null) {
property = new PersistedProperty(propertyTemplate, v, f);
} else {
property.setValue(v);
}
dao.merge(property);
Then u will get next exception:
java.util.ConcurrentModificationException
at java.util.ArrayList$Itr.checkForComodification(ArrayList.java:901)
at java.util.ArrayList$Itr.next(ArrayList.java:851)
at java.util.Collections$UnmodifiableCollection$1.next(Collections.java:1042)
at org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:587)
at org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:463)
at org.hibernate.event.internal.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:337)
at org.hibernate.event.internal.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:39)
at org.hibernate.internal.SessionImpl.doFlush(SessionImpl.java:1435)
at org.hibernate.internal.SessionImpl.managedFlush(SessionImpl.java:491)
at org.hibernate.internal.SessionImpl.flushBeforeTransactionCompletion(SessionImpl.java:3201)
at org.hibernate.internal.SessionImpl.beforeTransactionCompletion(SessionImpl.java:2411)
at org.hibernate.engine.jdbc.internal.JdbcCoordinatorImpl.beforeTransactionCompletion(JdbcCoordinatorImpl.java:467)
at org.hibernate.resource.transaction.backend.jdbc.internal.JdbcResourceLocalTransactionCoordinatorImpl.beforeCompletionCallback(JdbcResourceLocalTransactionCoordinatorImpl.java:146)
at org.hibernate.resource.transaction.backend.jdbc.internal.JdbcResourceLocalTransactionCoordinatorImpl.access$100(JdbcResourceLocalTransactionCoordinatorImpl.java:38)
at org.hibernate.resource.transaction.backend.jdbc.internal.JdbcResourceLocalTransactionCoordinatorImpl$TransactionDriverControlImpl.commit(JdbcResourceLocalTransactionCoordinatorImpl.java:220)
at org.hibernate.engine.transaction.internal.TransactionImpl.commit(TransactionImpl.java:68)
at org.springframework.orm.jpa.JpaTransactionManager.doCommit(JpaTransactionManager.java:517)
at org.springframework.transaction.support.AbstractPlatformTransactionManager.processCommit(AbstractPlatformTransactionManager.java:761)
at org.springframework.transaction.support.AbstractPlatformTransactionManager.commit(AbstractPlatformTransactionManager.java:730)
at org.springframework.transaction.interceptor.TransactionAspectSupport.commitTransactionAfterReturning(TransactionAspectSupport.java:504)
at org.springframework.transaction.interceptor.TransactionAspectSupport.invokeWithinTransaction(TransactionAspectSupport.java:292)
at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:96)
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179)
at org.springframework.aop.framework.CglibAopProxy$DynamicAdvisedInterceptor.intercept(CglibAopProxy.java:673)
Problem is deep repeat of same instance of ActionQueue in AbstractSaveEventListener (line 318) and final modification of ActionQueue by inner transaction.

In the documentation, there is a section called Conditional Auditing that discusses this.
The basic notion is you will need to override the Hibernate event listeners that Envers registers to handle triggering the auditing with your own custom implementations.
Your implementation will basically need to extend the Envers listeners and:
Check that the event is for the entity-type you're interested in skipping.
Check the modified state to see if only the condition that implies skipping occurred.
If you want to skip, simply don't delegate to the super implementation.
If you are using the ValidityAuditStrategy instead of the DefaultAuditStrategy, I would highly recommend you avoid using conditional auditing for INSERT operations.
Using conditional auditing on UPDATE operations from what I can tell will work, but doing so on the original inserts will cause the ADD row never to be added and thus the ValidityAuditStrategy will assert on the first UPDATE you attempt to audit for that entity row.
The goal in Hibernate 6 is to move beyond the need for users to manipulate the event listeners for conditional auditing and move toward a more JPA event listener annotation like approach. For more details, see HHH-11326.

Related

How to copy/clone DbContextOptions<AContext> to a DbContextOptions<BContext>?

Setting:
One db with many tables, grouped by modules. The moduleTableGroups are independent, there are no relationships in between.
Design:
1: The modules have each there own Context, to keep them small and clear.
2: Because it is an very old Database with manual administration of PKeys and sequences it must be possible to nest SaveChanges, when handling those things in the context.
E.G. AContext has a table with an entity which has a ValueGenerator which reads an incremented value from a table. Because it should be finished before AContext.SaveChanges(), is called, it must be done in an seperate SeqContext in the same db which can handle the concurency issues which might occur.
The SeqContext depends on the DbOptionsContext of AContext.
Wishes:
1: Instead of create Options for each Context which is currently needed, becaus a context seems only to accept context specific options, I'd like to either use the same DbContextOptions for many context or copy or cast the options to a new .
DbContextOptions<AContext> aContextOptions = new DbContextOptionsBuilder<AContext>(). . .Options;
// casting:
DbContextOptions<BContext> bContextOptions = (DbContextOptions<BContext>) aContextOptions;
// copy construction:
DbContextOptions<BContext> bContextOptions = new DbContextOptionsBuilder<BContext>(aContextOption).Options;
2: Because of the dependency of SeqContext to AContext especially in testing scenarios it would be useful to do something from within a AContext like:
SeqContext = new SeqContext((DbContextOptions<SeqContext>) this.getOptions());
You might get the idea. How can I archive to share options between different TContext right now?

Save update of one Doctrine document from preUpdate hook of another document?

I have an event subscriber for DocumentA. DocumentA has associated documents of type DocumentB. During the preUpdate lifecycle event hook for DocumentA, I'd like to refresh a value on its DocumentB. I have code like so:
public function preUpdate(LifecycleEventArgs $args)
{
$document = $args->getDocument();
if (!($document instanceof DocumentA) ||
return;
}
if ($documentsB = $document->getDocumentB()) {
$dm = $args->getDocumentManager();
foreach (iterator_to_array($documentsB) as $docB) {
$documentB = $dm->find(DocumentB::class, $docB->getId());
$documentB->setFooCode();
$dm->merge($documentB);
}
}
}
I've tried this with $dm->persist($documentB) instead of using merge(), I've set DocumentA's relationship to DocumentB to cascade: {all}, and I've tried $dm->getUnitOfWork()->recomputeSingleDocumentChangeSet($class, $document); for both DocumentA and each DocumentB, but I don't seem to be getting anywhere. I don't seem to be able to call flush() even for a single DocumentB without causing a segfault (I'm assuming it triggers an infinite loop of preUpdate events inside preUpdate events?)
How do I save the changes to my associated documents when the changes are made in the preUpdate method of DocumentA's event subscriber?
I elaborated on this further in one of your previous questions, but to reiterate from Doctrine's documentation:
Changes to associations of the updated entity are never allowed in this event
-Changes to associations of the passed entities are not recognized by the flush operation anymore.
With the level of complexity you are trying to handle in a listener, I think you would be better off making a service that handles some of this and call that instead.

Django Tastypie, Remove Elements From ManyToMany Fields

I am using Tastypie, Django for my project.
To Update a many to many field I have used save_m2m hook.
def save_m2m(self, bundle):
for field_name, field_object in self.fields.items():
if not getattr(field_object, 'is_m2m', False):
continue
if not field_object.attribute:
continue
if field_object.readonly:
continue
related_mngr = getattr(bundle.obj, field_object.attribute)
related_objs = []
print bundle.data[field_name]
for related_bundle in bundle.data[field_name]:
try:
stock = Stock.objects.get(nse_symbol = related_bundle.obj.nse_symbol)
print stock.__dict__
except Stock.DoesNotExist as e:
dataa = {"error_message": e}
raise ImmediateHttpResponse(response=HttpBadRequest(content=json.dumps(dataa), content_type="application/json; charset=UTF-8"))
related_objs.append(stock)
related_mngr.add(*related_objs)
Now I want to remove elements from the same many to many field.
How should I achieve this. Do I have to send a patch request or delete request and how to handle this.
I am begineer in tastypie. I googled it some time and I couldn't find a proper way. Please guide me how to complete this.
Thanks.
I've thought a lot about handing m2m relationships, since most of our app depends on m2m links.
I've settled for the approach of an update method. Pass in the all the references of the relationships you want changed (add and remove), then update the db accordingly. We only pass in the changed values, since if you have a paginated list, you only want to update the items the user has identified. Generally I use a custom hook for this defined in override_urls.
I used to have a separate add and remove method, which worked well until we changed the gui and allowed users simply to change checkboxes. In that approach having an update method was much more useful. You'll have to decide on which method suits your application the best.

Navigation Property Filter

My question is this: How can you implement a default server-side "filter" for a navigation property?
In our application we seldom actually delete anything from the database. Instead, we implement "soft deletes" where each table has a Deleted bit column. If this column is true the record has been "deleted". If it is false, it has not.
This allows us to easily "undelete" records accidentally deleted by the client.
Our current ASP.NET Web API returns only "undeleted" records by default, unless a deleted argument is sent as true from the client. The idea is that the consumer of the service doesn't have to worry about specifying that they only want undeleted items.
Implementing this same functionality in Breeze is quite simple, at least for base entities. For example, here would be the implementation of the classic Todo's example, adding a "Deleted" bit field:
// Note: Will show only undeleted items by default unless you explicitly pass deleted = true.
[HttpGet]
public IQueryable<BreezeSampleTodoItem> Todos(bool deleted = false) {
return _contextProvider.Context.Todos.Where(td => td.Deleted == deleted);
}
On the client, all we need to do is...
var query = breeze.EntityQuery.from("Todos");
...to get all undeleted Todos, or...
var query = breeze.EntityQuery.from("Todos").withParameters({deleted: true})
...to get all deleted Todos.
But let's say that a BreezeSampleTodoItem has a child collection for the tools that are needed to complete that Todo. We'll call this "Tools". Tools also implements soft deletes. When we perform a query that uses expand to get a Todo with its Tools, it will return all Tools - "deleted" or not.
But how can I filter out these records by default when Todo.Tools is expanded?
It has occurred to me to have separate Web API methods for each item that may need expanded, for example:
[HttpGet]
public IQueryable<Todo> TodoAndTools(bool deletedTodos = false, bool deletedTools = false)
{
return // ...Code to get filtered Todos with filtered Tools
}
I found some example code of how to do this in another SO post, but it requires hand-coding each property of Todo. The code from the above-mentioned post also returns a List, not an IQueryable. Furthermore this requires methods to be added for every possible expansion which isn't cool.
Essentially what I'm looking for is some way to define a piece of code that gets called whenever Todos is queried, and another for whenever Tools is queried - preferably being able to pass an argument that defines if it should return Deleted items. This could be anywhere on the server-side stack - be it in the Web API method, itself, or maybe part of Entity Framework (note that filtering Include extensions is not supported in EF.)
Breeze cannot do exactly what you are asking for right now, although we have discussed the idea of allowing the filtering of "expands", but we really need more feedback as to whether the community would find this useful. Please add this to the breeze User Voice and vote for it. We take these suggestions very seriously.
Moreover, as you point out, EF does not support this.
But... what you can do is use a projection instead of an expand to do something very similar:
public IQueryable<Object> TodoAndTools(bool deleted = false
,bool deletedTools = false) {
var baseQuery = _contextProvider.Context.Todos.Where(td => td.Deleted == deleted);
return baseQuery.Select(t => new {
Todo: t,
Tools: t.Tools.Where( tool => tool.Deleted = deletedTools);
});
}
Several things to note here:
1) We are returning an IQueryable of Object instead of IQueryable of ToDo
2) Breeze will inspect the returned payload and automatically create breeze entities for any 'entityTypes' returned (even within a projection). So the result of this query will be an array of javascript objects each with two properties; 'ToDo' and 'Tools' where Tools is an array of 'Tool' entities. The nice thing is that both ToDo and Tool entities returned within the projection will be 'full' breeze entities.
3) You can still pass client side filters based on the projected property names. i.e.
var query = EntityQuery.from("TodoAndTools")
.where("Todo.Description", "startsWith", "A")
.using(em);
4) EF does support this.

Update a table using JPA in Play Framework

I'm trying to update a table using JPA
EntityManager em=JPA.em();
EntityTransaction entr = em.getTransaction();
try{
if(!entr.isActive())
entr.begin();
Tblrecordtypefields updateTblrecordtypes = em.find(Tblrecordtypefields.class,9);
updateTblrecordtypes.setFieldlabel("JPATest");
em.getTransaction().commit();
}finally
{
if(entr.isActive())
entr.rollback();
}
i'm getting the error
NullPointerException occured : null at
updateTblrecordtypes.setFieldlabel("JPATest");
What should i do.
I see some possible issues in there:
First, Play manages the transactions on it's own. A transaction is created at the beginning of the request and committed (rollback if exception) at the end. You are trying to force your way into it, that's not recommended. To manage the entity, just do an entity.save() to mark it as "to be saved" and don't do tht to ignore any changes.
Second, if you are using the Model class in Play (as you should) you can use the "find" and "findById" methods provided by this class. This is recommened, instead of using the EntityManager directly.
See the documentation for more information.
Basically, redo your code to follow the Play way, to avoid problems :)
EDIT: as a clarification, I'm not really answering your question on why you get the NPE, but I think that as you are forcing your way into the settings of the framework you might (maybe not!) be seeing unexpected artifacts that will dissapear once you fix your code to follow convention.
If after that you still have the error let us know :)
This means that there is no row with ID 9 in the database table mapped by the entity Tblrecordtypefields.
BTW: I find it very questionable to commit a transaction in a method which is not necessary the one that started the transaction.
I have changed my code as below
Tblrecordtypefields updateTblrecordtypeFields = Tblrecordtypefields.findById(9);
updateTblrecordtypeFields.setFieldlabel("Test");
validation.valid(updateTblrecordtypeFields);
if(validation.hasErrors())
{
updateTblrecordtypeFields.refresh();
}
else
{
updateTblrecordtypeFields.save();
}
in my model class
public void setFieldlabel(String fieldlabel) {
this.fieldlabel = fieldlabel;
}
Works Fine.....