Today I noticed that my timestamp property was being saved with only the date information, not the time information. That is when I queried the corresponding column I saw something like this.

> select TO_CHAR(timestamp, 'yyyy-mm-dd hh24:mi:ss') from foo;

2007-11-17 00:00:00

The timestamp property was represented in Java using a Date class. I thought of switching it to a Timestamp class but was dubious because the only real difference is that the Timestamp class stores fractional seconds.

Then I looked at /atg/commerce/order/orderrepository.xml and the corresponding OrderImpl.java and realized that it used the timestamp repository data type while I was using the date repository date type. Since the Oracle column data type was also timestamp I found when I switched the repository data type the time information was also saved.

> select TO_CHAR(timestamp, 'yyyy-mm-dd hh24:mi:ss') from foo;

2007-11-17 20:03:00 

The moral of the story is to use the timestamp repository data type, not the date repository data type.

ATG has more documentation about this though it is not entirely true, i.e. you can use the Date Java class type with the timestamp SQL type.

ATG allows one to use your own Java class data types for the properties of repository items. This is called User-Defined Property Types.

While working with these user-defined property types I learned a few things that are not explicitly documented.

1. The source for atg.repository.FilePropertyDescriptor is supplied in the installation and it’s a good example for creating your own user-defined property type.
2. To set values of properties in your Java class data type do two things.
   1. Configure the values of these properties using the attribute tag. For example:
      
<property name="contentFile" property-type="atg.repository.FilePropertyDescriptor">
<attribute name="pathNameProperty" value="contentFileName"/>
</property>
   2. Access these attributes and set the corresponding properties in the setValue() method. Continuing with the above example:
      
public void setValue(String pAttributeName, Object pValue) {
super.setValue(pAttributeName, pValue);

if (pValue == null || pAttributeName == null) return;
if (pAttributeName.equalsIgnoreCase(PATH_NAME_PROPERTY))
mPathNameProperty = pValue.toString();
if (pAttributeName.equalsIgnoreCase(PATH_PREFIX))
mPathPrefix = pValue.toString();
}

3. ATG’s documentation suggests it is not necessary to define the data-type attribute if you specify the type with the property-type attribute. However I found that sometimes ATG gets confused and that it is best practice to always set the data-type. So using the above example one would do this.
   
<property name="contentFile" data-type="string" property-type="atg.repository.FilePropertyDescriptor">
<attribute name="pathNameProperty" value="contentFileName"/>
</property>
4. Only one instance of your user-defined property type is ever instantiated. Even if your user-defined property type is used for multiple properties it will still only be instantiated once.
5. The JavaDoc for ATG’s RepositoryPropertyDescriptor class, which one typically extends to create ones own user-defined property type, documents the getPropertyValue method like this: public java.lang.Object getPropertyValue(RepositoryItemImpl pItem, java.lang.Object pValue)

   The first argument is the instance of the repository item whose property you are defining.

   The second argument would be better named pCachedPropertyValue because it is the cached property value. If it is null then that means there is no cached value. If it is not null that means that in a previous call setPropertyValueInCache(this, yourvalue) was called. Unfortunately this cached value is not that useful because since only one instance of your user-defined property type is ever created, the cached value will be a global value.

   This cached value is cleared when invalidateCaches is called on the repository item.

   Here is what ATG support said about caching with User-Defined Property Types.

   I think user defined properties will not be cached so that will cause your code to be
   called several times. If you require some caching you would properly have to
   implement it in the code of the user-defined property.

   As a user defined property could return data from any external source that might get
   updated independently of the ATG application we can not really make a decision on
   what should be cached and what should be retrieved anew every single time.

   Kind regards,
   Olaf Doemer

6. The property descriptor implements the Serializable interface so the developer must ensure that it is indeed serializable, i.e. all its members are serializable.