I use Hibernate with Envers and have an entity with some columns annotated with #Audited(withModifiedFlag = true), i.e. there is an additional boolean column in the _AUD table that indicates if the column was updated or not.
If I save a new entity, a corresponding entry is written in the _AUD table with revtype 0. I have a problem with the _MOD colum value. If the column is null the value of the _MOD entry is false and if there is a non-null value the _MOD entry is true. I think for a new entry (i.e. revtype=0) it's more logical to have all _MOD values set to false since the columns haven't been modified. Is there a way to achieve that?
The main reason those _MOD fields end up being set for values that are inserted initially is because all of the prior entity state is null and those comparisons yield differences (e.g. non-null != null) and therefore its seen as having been modified. The feature does not take into account whether the operation being performed is an INSERT, UPDATE, or a DELETE.
Personally, I find the current behavior more logical.
For that initial ADD operation, changing the behavior will force you to have some branch logic to deal with seed value changes based on revision number of revision type where-as simply using the _MOD field behavior as it is today implies you can simply ignore the revision type/number and just use the toggles on any query.
Unfortunately you cannot toggle this behavior presently.
We could look at adding a configuration parameter that would allow you to influence whether the ADD operation should be treated as a modification or not. If its something that you and others find useful, please feel free to open a JIRA here.
Related
We can define a parameter that is required and nullable in Flutter version 2, does it make sense? Why should we have a required parameter which accepts null?
In terms of database values like in SQL, NULL specifically refers to a "missing" value. In other words it references a value that could or will be defined but has not (yet) been.
To answer your question, it depends on what the field is and whether or not it's being stored in any kind of state, whether that state is front or back end.
One example where I would consider using a nullable but required field would be if I'm soft deleting records and am marking a deleted_at column. I want to require this field for a soft delete, but it is expected to not be defined until an actual delete occurs, whenever that is.
Flutter is basically a data-driven UI that should have one UI page for any given state. So if you, say, had a user record that was soft deletable on the backend and a profile user page that might be shown (to an admin or whatever), you might want to set the deleted_at field in the Dart code to be required but nullable to distinguish the state of a soft deletable user record.
I have a table in db2 which is having a varchar column. I want to insert only lower case string in the column.
Is it possible to change the case to lower whenever an insertion happens in that column. What will be the alter
Query for that if possible ?
I can not make another column which can take reference of my current column and be referenced like ucase(Current_column)
The means to ensure the effect of lower-casing the data that is inserted into a column, i.e. "to change the case to lower whenever an insertion happens in that column", is a TRIGGER.
Presumably much like Why is my “before update” trigger changing unexpected columns?, per having noted in a followup comment to the OP that "I tried making a BEFORE INSERT", a TRIGGER similar to the following apparently was implemented in that attempt?:
CREATE TRIGGER TOLOWER_BI BEFORE INSERT ON USERS
REFERENCING NEW AS N OLD AS O FOR EACH ROW MODE DB2ROW
set N.LoginId= lcase(N.LoginId)
If so, then "the application is not picking the trigger" [also from a followup comment to the OP] must be explained, because a TRIGGER is in effect at the database layer, such that an application has no choice [no picking] with regard to the effects of the trigger being enforced.
When I try to update a database with some modified values in a dataset, a concurrence exception doesn't raise if i change manually some values in the database after the fill method on the dataset is performed. (I only get the exception if I delete a row manually and then I try call the method update of data adapter).
How should I check if I have a "dirty read" on my dataset?.
You have several options.
Keeping a copy of the original entity set to compare against and make
the is dirty determination at the point you need to know whether it's
dirty.
Checking the datarow's rowstate property and if Modified compare
the values in the Current and Original DataRowVersions. If the second
change makes the value the same as the original then you could call
RejectChanges, however that would reject all changes on the row. You
will have to manually track each field since the dataset only keeps
per-row or per-table changes.
I have a hashmultimap, the current behavior of this data structure is whenever I try to insert a value that already exists, it does not insert, however I would like a different behavior: if the object I want to insert as value is equals, I want to update this value.
This behaviour is the result of HashMultimap using a standard HashSet for its value collection. The contract of Set#add is:
If this set already contains the element, the call leaves the set unchanged
However, the contract of multimap does not require this. If you create a Collection implementation that has the update behaviour you desire, you can use Multimaps#newMultimap to create a multimap using that backing collection type.
I would caution though that this requirement seems suspect...the fact that you're trying to update the value objects while they are being used in a Set is somewhat smelly. It could be that what you really want is something like Map<CompositeKey<CurrentKey, CurrentValue>, State>. Then the update behavior simply becomes a put.
I have a persisted computed column in one table with the value calculated using a user function. How can I force that column to be updated without updating any other column in that table?
UPDATE: So as it turns out, this will not work as I imagined it.
I wanted to have user function that contains sub-query in it, gets me some data and stores it in computed column. But SQL Server won't allow this...
It looks like I will have to do something similar with insert/update triggers.
If you persist the value by adding the PERSISTED keyword, the value is both retained on insert and will be synchronized when the referenced column is updated.