What is the uses of setNull() method in PreparedStatement interface? I looked in this post.
It says: Without the setNull(..) method there would be no way to set null values for the Java primitives.
however with autoboxing in JDK5, I think null values can be set on even primitive types.
There is another post in some other forum says:If you want to be portable to different databases, use the setNull() method.
However there is nothing clearly mentioned in Java doc. Could you help me understanding this?
I think it's easier to understand this if you view it from the database end. If you want to set a field to NULL in your database insert statement, then you need a way of telling the database that is should be set to NULL rather than the default value for the column. If in the database schema you have a nullable integer field, you would use set null to set it to the DB NULL value, rather than to its default value ( 0 ).
Related
I'm writing a simple webapp to show my coding skills to potential employers. It connects with an API and receives a JSON file which is then deserialized using Jackson and displayed in a table form in the browser. I want to enable the user to persist the Java object in a Postgres database using Hibernate. I got it to work and it does the job nicely but I want to make it more efficient.
Whenever there is no data in the JSON response to put in the object's field (right now all the possible JSON attributes are present in the Java class/Hibernate entity in the form of String fields) I put an empty String ('') and then, with all fields having something and no null objects, it is stored in the database.
Should I only store what I have and put no empty strings in the DB (using nulls instead) or is what I'm doing now the right way?
Null is an absence of a value. An empty string is a value. But that don't impact much to memory. If you want to display data repeatedly and don't want conversion from null to empty string while retrieval you can go for empty string ''.
But if you want unique constraint for values other than empty string '' then use null.
Sometimes null and empty '' can be used to differentiate either data was known or not. for known but not available data use empty and for unknown data null can be used.
Use NULLwhen there isn't a known value.
Never use the empty string.
For example, if you have a customer which didn't supply his address don't say his address is '', say it is NULL. NULL unambiguously states "no value".
For database columns that must have a value for your web application to work, create the backing table with NOT NULL data constraints on those columns.
In your unit tests, call NULL, ..._address_is_null_ and test for success or failure (depending on if the test should trigger no errors or trigger an exception).
The use of '' in databases as a sentinel, a special value that means something other that '', is discouraged. That's because we won't know what you meant it to mean. Also, there might be more than one special case, and if you use '' first, then it makes restructuring more difficult to add others (unless you fall into the really bad practice of using even more special strings to enumerate other special cases, like "deleted" and so on).
I was looking for a nice-looking way to extract a nullable value from a ResultSet, as opposite to wasNull. Documentation (API spec) guarantees that "untyped" getObject (returning Object) returns null when the column contains NULL, making the following construct valid: (Boolean)rs.getObject(1).
Naturally, I would prefer to do rs.getObject(1, Boolean.class) - but, for some reason, for the typed overload no such guarantees are provided.
Or are they? Maybe I am just missing something? I found nothing for this particular oveload at here , and JDBC spec seems to overlook such overloads entirely.
So, do NULLs get converted to nulls by rs.getObject(1, Boolean.class), or don't they, or is that implementation-dependent, or maybe it depends on some custom conversions defined in an application?
I wonder if there is way to know the types of results I retrieved from the database in java. Ultimately I want to be able to use appropriate get method for each column of the resultSet (or be able to convert getObject() to the proper type) without me knowing anything about the database/data explicitly.
You will need the ResultSetMetadata. Call getMetadata() on the ResultSest, then call getColumnType on the metadata object.
The returned value is from java.sql.Types.
The number, types and properties of a ResultSet object's columns are provided by the ResulSetMetaData object returned by the ResultSet.getMetaData method.
Use getMetaData(). It contains the type of each column, among other things.
I would like to have an option to call 'rawQuery' with a list of Integers passed into it, but it looks I can't: all 'rawQuery' methods require array of Strings...
Why? I can call 'toString' for each passed int object, but I don't see any logic here. Why Google don't provide rawQuery that accept list of Objects?
Are there any limitation or constrains for that?
Probably I miss something?
Thank you.
Probably because rawQuery isn't the prefered method of querying. And since sqlite columns basically don't have types, they probably don't want to assume calling toString on whatever it is you're passing.
SQLite supports the concept of "type affinity" on columns. The type
affinity of a column is the recommended type for data stored in that
column. The important idea here is that the type is recommended, not
required. Any column can still store any type of data. It is just that
some columns, given the choice, will prefer to use one storage class
over another. The preferred storage class for a column is called its
"affinity".
Is there a reason you want to use rawQuery instead of execSQL?
No complex objects are accepted in the list of parameters, as stated on the documentation for the parameter bindArgs:
Parameters
sql the SQL statement to be executed. Multiple statements separated by semicolons are not supported.
bindArgs only byte[], String, Long and Double are supported in bindArgs.
http://developer.android.com/reference/android/database/sqlite/SQLiteDatabase.html#execSQL(java.lang.String, java.lang.Object[]).
When I create a new instance and then flush() my Hibernate Session, are all properties of this instance marked as dirty, including the null ones?
Or are only those properties dirty that aren't null?
There is no dirty values not in Java neither in DBMS (Mysql for example). By default in java all primitive types takes specified zero values and all links takes null as value. The same for DBMS, when you insert a record in table field of record initialized with default values.