Hi,
I think it does not make sense to use prePersist and postAdd,
prePersist is called every time the object is committed and you only
need default values after creation.
And also it doesn't make sense to use postAdd with mandatory fields
without default values, your business logic (or daos) should have the
responsability of setting the correct values in each case, otherwise you
will generate an Exception, but that's okay as something that shouldn't
happen has happened so a good Exception handling (or at least logging)
is mandatory to fix this kind of logic errors on the long run.
Anyway, in my experience, prePersist is not working as documented,
indeed I think it is not being called on object creation, and thats why
your first example it is not working.
El 11/10/2012 10:10, [email protected] escribió:
Thanks Andrus & Ramiro
Setting default values in the onPostAdd callback makes sense.
What about mandatory fields without default values ?
I suppose one could put in a dummy value in onPostAdd to circumvent the
validation execption.
But would this be good practice as this would prevent a validation
exception occurring after onPrePersist, if the field hasn't been properly
set.
So if one forgot to set its proper value say at the last in the
onPrePersist callback then this i think would defeat the point of having
sensible mandatory data.
Based on this imho the current docs describe the correct behavior that
PrePersist is called "Prior to commit (and prior to "validateFor*")
within ObjectContext.commitChanges()".
However the implementation doesn't seem to follow this, or am i missing
something ?
What do you guys think ?
Yeah, I guess PostAdd is the right callback to init new object defaults.
We are rewriting the docs for 3.1. May need to clarify it there.
(and sorry for the late reply).
On Oct 10, 2012, at 3:17 PM, Ramiro Aparicio <[email protected]>
wrote:
Umm we found the same pattern some time ago, and just moved our default
values to onPostAdd, and I that is working fine for us, but I am not
sure if we are using it with mandatory fields.
El 10/10/2012 13:42, [email protected] escribió:
Does anybody have any news on this, please ?
Thanks.
---------------------------- Original Message
----------------------------
Subject: Re: 3.1B1 Validation Exception
Date: Thu, September 20, 2012 11:27
--------------------------------------------------------------------------
Not sure how to submit the example, but here goes:
1. TestMap.map.xml
<?xml version="1.0" encoding="utf-8"?>
<data-map xmlns="http://cayenne.apache.org/schema/3.0/modelMap";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://cayenne.apache.org/schema/3.0/modelMap
http://cayenne.apache.org/schema/3.0/modelMap.xsd";
project-version="6">
<property name="defaultPackage" value="test.tables"/>
<db-entity name="DOCUMENTS">
<db-attribute name="CLEINT_NO" type="VARCHAR" isMandatory="true"
length="50"/>
<db-attribute name="DOC_DATE" type="TIMESTAMP"
isMandatory="true"/>
<db-attribute name="DOC_ID" type="BIGINT" isPrimaryKey="true"
isGenerated="true" isMandatory="true"/>
<db-attribute name="DOC_INFO" type="CLOB" isMandatory="true"/>
<db-attribute name="DOC_REF_NO" type="VARCHAR"
isMandatory="true"
length="50"/>
</db-entity>
<obj-entity name="Document" className="test.tables.Document"
dbEntityName="DOCUMENTS">
<obj-attribute name="client_id" type="java.lang.String"
db-attribute-path="CLEINT_NO"/>
<obj-attribute name="docDate" type="java.sql.Timestamp"
db-attribute-path="DOC_DATE"/>
<obj-attribute name="info" type="java.lang.String"
db-attribute-path="DOC_INFO"/>
<obj-attribute name="reference" type="java.lang.String"
db-attribute-path="DOC_REF_NO"/>
<pre-persist method-name="onPrePersist"/>
</obj-entity>
</data-map>
--------------------------------------------------------------------
2. Document class
package test.tables;
import java.sql.Timestamp;
import test.tables.auto._Document;
public class Document extends _Document
{
@Override
protected void onPrePersist()
{
setDocDate( new Timestamp( System.currentTimeMillis() ) );
}
}
--------------------------------------------------------------------
3. Test class
import org.apache.cayenne.configuration.server.ServerRuntime;
import test.tables.Document;
public class Test
{
public static void main( String[] args )
{
ServerRuntime server = new ServerRuntime("cayenne-Test.xml");
Document newDoc = server.getContext().newObject(
Document.class );
newDoc.setClient_id( "12345" );
newDoc.setReference( "Test entry" );
newDoc.setInfo( "Some text about stuff." );
newDoc.getObjectContext().commitChanges();
}
}
--------------------------------------------------------------------
4. The Exception
Exception in thread "main"
org.apache.cayenne.validation.ValidationException: [v.3.1B1 May 28 2012
20:59:56] Validation failures: Validation failure for
test.tables.Document.docDate: "docDate" is required.
Validation failure for test.tables.Document.docDate: "docDate" is
required.
at
org.apache.cayenne.access.ObjectStoreGraphDiff.validateAndCheckNoop(ObjectStoreGraphDiff.java:111)
at
org.apache.cayenne.access.DataContext.flushToParent(DataContext.java:806)
at
org.apache.cayenne.access.DataContext.commitChanges(DataContext.java:756)
at Test.main(Test.java:16)
--------------------------------------------------------------------
Thanks.
That doesn't sound like the right behavior. Can you create small
example
that reproduces the problem?
On Wednesday, September 19, 2012, wrote:
Is this a bug or am I doing something wrong ?
I'm using 3.1B1 and getting a validation exception BEFORE my
onPrePersist lifecycle method is called ?
Caused by: org.apache.cayenne.validation.ValidationException:
[v.3.1B1
May 28 2012
20:59:56]org.apache.cayenne.access.ObjectStoreGraphDiff.validateAndCheckNoop(ObjectStoreGraphDiff.java:111)
at
org.apache.cayenne.access.DataContext.flushToParent(DataContext.java:806)
at
org.apache.cayenne.access.DataContext.commitChanges(DataContext.java:756)
The Cayenne Guide\Lifecycle Callbacks documentation indicates that
PrePersist is called "Prior to commit (and prior to "validateFor*")
within ObjectContext.commitChanges()"
However from the above this doesn't seem to be the case ?
So is this a bug or am I missing something ?
