We have an NHibernate app that we are migrating from SQL Server to Oracle. Our optimistic concurrency is implemented via a <timestamp name="Version"> mapping element.
The data type of the corresponding Version column in Oracle is DATE. After we save an object, the in-memory C# object is left with a timestamp value in milliseconds (e.g. 12:34:56.789) while the value in the database is precise only to the second (e.g. 12:34:56). Thus, if we attempt to save the object a 2nd time, we get a StaleStateException because the two values do not match.
I attempted to fix this by altering the data type of the Version column to TIMESTAMP(3). Unfortunately, the C# object and the DB value are still off by one millisecond (e.g. 12:34:56.789 vs 12:34:56.788), so the 2nd attempt to save the object still causes a StaleStateException.
What can I do to create a working <timestamp> mapping to an Oracle column of type DATE or TIMESTAMP so that the same object can be saved multiple times?
Thanks.
-- Brian
TIMESTAMP(7) has the correct precision to match the .NET DateTime class and fixed the problem.
Related
TLDR; is there a way to understand at runtime which format is ADF using for dates behind the scenes? In particular the format used to render dates in dynamically generated sql code?
In the Oracle ADF Application I'm working on there are several table filters (by that I mean the field over the column in which I can write text/number/dates to query the table).
Filtering this way, the framework modifies the query of the View Object, adding the appropriate where clause. On the page there's also a button "Select all" that allows me to select all the data that's rendered in the table (there is a selection checkbox).
In the specific case, the query from the VO is used to aim two different goals:
update the rendered data in the table
if I press the "select all" button a function in the backend database is called (callable statement calling the function), passing as a parameter the query.
The first task is successfully reached (as the table is visually updated), but we had an issue with the second one.
The backend function uses the query to select all the extracted data (as iterating in ADF with java would be too slow).
The problem is that the where clause isn't correctly generated for the backend database (which is also oracle).
Basically the generated WHERE clause (which was added to VO's query automatically by the framework) was
WHERE record_date = '2020-10-12'
which I had to change to
WHERE record_date = to_date('2020-10-12', 'YYYY-MM-DD')
in order to have it correctly executed by the Oracle Db.
So now it's working (yay), but my concern is: isn't it dangerous to assume the date format will be 'YYYY-MM-DD' on every application's instance?
I think this 'YYYY-MM-DD' is the format in which ADF is managing dates (as the value is written as '2020-10-12' in the query).
But is there a way to understand at runtime which format is ADF using for dates behind the scenes? Or does it always use 'YYYY-MM-DD', or am I completely off-road and the storage format is another and I should ask which format does it use to render dates? But dates on page are visually rendered in another way :/
Sorry for my lack of expertise and have a nice day!
Update
The value of the query field, which I'm getting by calling
this.getNamedWhereClauseParams().getAttribute('vc_temp_1');
is of class
oracle.jbo.domain.Date
and by printing it I obtain the date in format YYYY-MM-DD.
Would it be possible that the framework was simply using Date.toString?
This would raise another question: how can I be sure of the pattern used by Date.toString? The documentation isn't clear about it (and it says that it should be used only in development, so this is quite a remote scenario).
What you named 'Filter' is called 'Query by Example' or QBE in short. See the doc for more info.
You can change the query passed to the server using a bean method. Look at e.g. JDev 12.2.1.3: Multi select component table filter for a sample.
Using dates in ADF is always dependent on the current user's settings. If the user don'T use a specific locale the default is 'yyyy-mm-dd'. This can be changed at different points, starting by the entity objects, view objects a,d finally in the UI by using converters.
The best way to use dates depends on the use case.
I have a situation where a table in the database has a date field defined as date where time also is important (for sorting later).
At first, all times for the date where coming as 000000 but I updated the code to use timestamp and when inserting new records, it's working fine.
Update on the other hand will not change the database if the date is the same (but different time). Apparently, while inserting, hibernate doesn't take into consideration the time and the record is not change (or at least this is what I discovered from my testing).
I can't change the database structure to use timestamp or add a time field.
Any help is really appreciated :)
Thanks
Does hibernate have any mapping for this oracle data type:(10G)
TIMESTAMP(6) WITH TIME ZONE
I am getting:
No Dialect mapping for JDBC type: -101
My manager does not want to do the: registerHibernateType(-101, Hibernate.getText().getname())
He thinks it is too much.:)
What alternative can I have?
The answer you provide to yourself is more like a workaround than a proper solution. For the sake of the visitors looking for an answer, I'll provide my view on this:
1) Database date-based fields should be always set to UTC, never with a specific timezone. Date calculation with timezone information is an unneeded complexity. Remember that timezones usually changes twice a year for a lot of countries in the world ("daylight saving time"). There's a reason why only a few RDMBS' supports this, and there's a reason why Hibernate developers refuse to support this data-type. The patch for Hibernate is simple enough (one line of code), the implications aren't.
2) Converting your "timestamp with timezone" to a String will only cause problems later. Once you retrieve it as String, you'll need to convert it again to a Date/Calendar object, an unneeded overhead. Not to mention the risks associated with this operation.
3) If you need to know in which timezone is some user, just store the String representing the timezone offset (like "Europe/Prague"). You can use this in Java to build a Calendar with date/time and timezone, as it'll take care of DST for you.
For now, I solved the problem by:
`select TO_CHAR(TRUNC(field)) from table` //field is the one having type= timestamp with timezone
This ensures that when the query returns, the field has datatype 'String'
I currently have an existing database and I am using the LINQtoSQL generator tool to create the classes for me. The tool is working fine for this database and there are no errors with that tool.
When I run a LINQ to SQL query against the data, there is a row that has some invalid data somehow within the table and it is throwing a System.FormatException when it runs across this row. Does anyone know what that stems from? Does anyone know how I can narrow down the effecting column without adding them one by one to the select clause?
Do you have a varchar(1) that stores an empty string?
You need to change the type from char to string in the designer (or somehow prohibit empties). The .net char type cannot hold an empty string.
I'm storing a simple java.util.date in an Oracle XE database via hibernate.
When testing with JUnit if I can retrieve the correct value, I get an error like this:
junit.framework.AssertionFailedError:
expected:<Sun Dec 28 11:20:27 CET 2008>
but was:<2008-12-28 11:20:27.0>
The value is stored in an Oracle Date column (which should have a second-precision) which looks okay to me. Also, I'm surprised that 11:20:27 is not equal to 11:20:27.0. Or does this have to do with timezones?
Any help is welcome.
Thorsten
Okay, worked some more on it ...
Oracle Date columns only store values with an accuracy of a second.
Java Dates do contain milliseconds, but they are typically not printed. So
expected:
was actually created by a date like 11:20:27,345, which is of course not equal to 11:20:27.0
Solution:
either only use full second dates to store and retrieve
or
get hibernate to create the correct Oracle Datatype (TIMESTAMP) - this is very dependent on the dialect specified in the hibernate config (OracleDialect and Oracle10gDialect create different types).
If you compare a java.util.Date to a java.sql.Date that both represent the same instant in time, equals(Object) will return false (it considers two objects of different classes to never be equal).
Your tests need to account for that. The easiest way to do this is to convert the dates to UNIX time (e.g. java.util.Date.getTime()) and compare those values.