NullPointerException in DataSource.binaryMetadataIsDifferent()

[claudiobosticco]

SmartClient Version: v13.1p_2025-12-31/AllModules Development Only (built 2025-12-31)

Hi, and a Happy New Year.

I have a DataSource with audit enabled where I am making some changes, adding an imageFile field along with its related metadata fields.

As a first step, I would prefer not to have audit enabled on these fields, so I marked them with audit="never". However, I am now encountering a NullPointerException.

From what I can see, it happens in the method DataSource.binaryMetadataIsDifferent(), where the variables newName, oldName, newSize, and oldSize are all null, which then causes an exception at this line:

return newName == null && oldName != null || !newName.equals(oldName) ...

Is this a bug, or am I doing something that is not supported or not allowed?

[Isomorphic]

We've fixed the NullPointerException you discovered back to SC 13.1. The fix will be available in the nightly builds dated 2026-01-06 or later.

Let us know if you are still hitting issues after updating.

[claudiobosticco]

SmartClient Version: v13.1p_2026-01-06/Enterprise Deployment (built 2026-01-06)

I can confirm that now my code is working, thanks.

Out of curiosity, is it correct that the binaryMetadataIsDifferent method is called given that the binary field and the related metadata fields are marked with audit="never"?

[Isomorphic]

Thanks for pointing this out. We've made an optimziation in this area now that should skip throwaway work. it should be in the next nightly builds.

[claudiobosticco]

Hi, nice, I see the optimization.

I’ve now enabled auditing on the binary field.

When using Oracle, I’ve always created column names in the database and field names in the DataSources in uppercase.
Accordingly, I’ve also always created the metadata fields for binary fields with uppercase names (e.g. with the _FILESIZE suffix), and I’ve never encountered any issues.

However, I’m now realizing that, as far as auditing is concerned-at least in the binaryMetadataIsDifferent and isBinaryMetadata methods of the DataSource class-the _filesize casing is used (whereas in the getMetadataField method I see an equalsIgnoreCase).

Do I need to change the case of my fields, or should it work as it is?

[Isomorphic]

The default in Oracle is that column names are case insensitive unless you actually use quotation marks when creating the columns.

Presumably you haven't done that, so, nothing to fix.

[claudiobosticco]

Thanks, I understand how Oracle handles column names. I don't use quotation marks when creating the columns and I usually define DSFields uppercase.

My concern, however, is not the DB lookup, but the Java code in DataSource class:
in binaryMetadataIsDifferent / isBinaryMetadata the metadata field names seem to be matched case-sensitively against _filesize.

I’ve already verified that the audit logic does not detect changes on binary metadata fields when they are named _FILESIZE (uppercase).

Since this is the first time I’ve ever hit a case-related issue on field names, it didn't look like an intentional behavior to me.

Can you please confirm whether binary metadata field names are expected to be case-sensitive for audit purposes, or if this should be handled case-insensitively (as already done in getMetadataField)?

[Isomorphic]

When SmartClient issues queries to a DB, once the fields are in-memory in Java, they are always case sensitive (because that's just how Maps work).

If SmartClient is the system querying the DB, they will end up in the correct case in memory regardless of the DB case.

So it's not clear what you're testing - presumably you mean that you tried manually adding metadata values yourself? In that case yes, if you get the case wrong, that won't work. But that has nothing to do with the SQL case; it would be true of any DataSource no matter the data provider.

[claudiobosticco]

What is happening is that binaryMetadataIsDifferent returns false because it looks for LOGO_filesize, while the Map contains LOGO_FILESIZE:




This leads to my question: do I actually need to rename my DSFields to LOGO_filesize, etc., for the audit logic to work correctly?

[Blama]

Hi all,

I (not OP) assume that claudiobosticco is saying there is a hardcoded "_filesize" somewhere in the Java code of binaryMetadataIsDifferent() / isBinaryMetadata() and that you do a case-sensitive match against this. Correct?

Best regards
Blama

[claudiobosticco]

Hi Blama , yes, the filesize_ (etc.) strings in the code are lowercase, and since they are used with Map.get(), the lookup is clearly case-sensitive.

Before going ahead and correcting all the metadata fields in my DataSources, I wanted an official confirmation or denial.

I also found an old thread where someone had an issue related to metadata fields being defined in all uppercase: https://forums.smartclient.com/forum...395#post165395

[Isomorphic]

You do have to rename the metadata fields in the DataSource - they cannot be renamed (little point to that). You can, however, explicitly redeclare them if you want to set a custom title or make them visible by default, or whatever other changes you like.

You don't have to rename anything in the DB because that's not case-sensitive.

[claudiobosticco]

Thanks for the confirmation.

It may be worth calling this out more clearly in the documentation, as using a different case for binary metadata fields does not seem to cause issues elsewhere, but silently breaks audit change detection.

[Isomorphic]

The names of the fields are documented on FieldType ("binary") but we can add a blurb explicitly saying they cannot be renamed.

Note that using a name other than the documented one would just break every feature related to the metadata fields - there isn't some kind of inconsistency where some features work that way and others don't. The system would just be totally unaware that your custom field declaration was intended to be related to the binary field at all.

[claudiobosticco]

Hi, yes, you’re absolutely right. I hadn’t realized that the framework is actually ignoring my *_FILENAME, etc. fields, and that things only appear to be working because, on the Oracle side, the auto-generated *_filename, etc. fields are still being stored (since Oracle is case-insensitive) and then, of course, fetched using the names of my uppercase fields.