Re: no state snapshot available on embedded mapping
What is the identity strategy used by the Order.class? While reproducing the error, that factor *seems* to be crucial than whether there is a embedded field. Can you verify if there is a change in behavior if Order.class uses datastore vs application identity? Marc Logemann-3 wrote: > > and yes, for the record: i changed to build time enhancement and now > embedded entities work. Still interessted in the "why" answer. > > -- > Marc Logemann > blog http://logemannreloaded.blogspot.com > privat http://www.logemann.org > > > > Am 14.07.2008 um 16:22 schrieb Pinaki Poddar: > >> >> Hi, >> Are you using runtime enhancement with Java 5? >> If yes, the immediate workaround is to enhance the persistent >> classes at >> build-time. >> >> -- >> View this message in context: >> http://n2.nabble.com/no-state-snapshot-available-on-embedded-mapping-tp526616p527331.html >> Sent from the OpenJPA Users mailing list archive at Nabble.com. >> > > > -- View this message in context: http://n2.nabble.com/no-state-snapshot-available-on-embedded-mapping-tp526616p527706.html Sent from the OpenJPA Users mailing list archive at Nabble.com.
Re: no state snapshot available on embedded mapping
here we go: https://issues.apache.org/jira/browse/OPENJPA-659 -- Marc Logemann blog http://logemannreloaded.blogspot.com privat http://www.logemann.org Am 14.07.2008 um 18:24 schrieb Craig L Russell: Could you please file a JIRA with the relevant detail? Thanks, Craig
Re: no state snapshot available on embedded mapping
Hi,
I am not familiar enough with runtime enhancement, so please accept my
explanation with certain degree of disbelief.
OpenJPA tracks the dirty fields of managed instances and traditional
(i.e. build-time) enhancement ensures that at bytecode level on field
mutators. Runtime enhancement is also able to track dirty fields
when
a) Java 6 is the runtime
b) Java 5 and entity using property access and are loaded from database
(not for new instances)
In Java 5, the entities with field access are not tracked and hence
during commit session, OpenJPA resorts to state comparison for such cases.
This checking is skipped on certain cases, as described below:
private boolean needsDirtyCheck() {
if (isIntercepting())
return false;
if (isDeleted())
return false;
if (isNew() && !isFlushed())
return false;
+if (!isTransactional())
+return false;
return true;
}
Including non-transactional entities to skip dirty check resolves the
issue you have encountered. Exclusion of nontransactional entities form
dirty checking sounds logical to me but due to my limited understanding of
runtime enhancement I am not able to confirm.
* Fields are tracked for all classes that are run through the
OpenJPA
* enhancer prior to or during deployment, and all classes (enhanced or
* unenhanced) in a Java 6 environment or newer.
*
* In a Java 5 VM or older:
* - instances of unenhanced classes that use
* property access and obey the property access limitations are tracked
* when the instances are loaded from the database by OpenJPA, and are
* not tracked when the instances are created by application code.
* - instances of unenhanced classes that use field access are
* never tracked.
Change tracking of classes
Marc Logemann-3 wrote:
>
> Hi,
>
> yes, i am using a spring-tomcat-weaver.jar in Tomcat6 (with Java5) to
> achieve JPA runtime enhancement via Spring.
>
> What do you mean with workaround? Should this work "normally" ? I was
> quite happy with runtime enhancement, would be sad to leave that
> path
>
> thx for infos
>
> --
> Marc Logemann
> blog http://logemannreloaded.blogspot.com
> privat http://www.logemann.org
>
>
>
> Am 14.07.2008 um 16:22 schrieb Pinaki Poddar:
>
>>
>> Hi,
>> Are you using runtime enhancement with Java 5?
>> If yes, the immediate workaround is to enhance the persistent
>> classes at
>> build-time.
>>
>> --
>> View this message in context:
>> http://n2.nabble.com/no-state-snapshot-available-on-embedded-mapping-tp526616p527331.html
>> Sent from the OpenJPA Users mailing list archive at Nabble.com.
>>
>
>
>
--
View this message in context:
http://n2.nabble.com/no-state-snapshot-available-on-embedded-mapping-tp526616p527542.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.
Re: JPA question and i18n problem
Hi,
This problem can be solved using following two extended features of
OpenJPA
1. Using entity relation as primary key
2. Using non-standard joins
Sculpture will simply declare a one-to-one relation to its localized
description.
public class Sculpture {
@OneToOne(mappedBy="sculpture")
private LocalizedDescription desc;
Though there are more than one description for a Sculpture, our mapping will
ensure that the relation is 'logically' one-to-one based any given locale.
While the LocalizedDescription class will look like
@Entity
@Table(name="Sculpture_i18n")
@IdClass(LocalizedDescription.CompoundId.class)
public class LocalizedDescription {
@Id
@ManyToOne
@JoinColumns({
@JoinColumn(name="sculpture_id",
referencedColumnName="sculpture_ID"),
@JoinColumn(name="locale", referencedColumnName="'en'")
})
private Sculpture sculpture;
@Id
@Column(name="locale")
private String locale;
...
}
Few noteworthy points in this class are
1. The class uses its entity relation field 'sculpture' as a part of a
compound primary key. This is not supported by JPA specification, but is
supported by OpenJPA.
2. The class uses a separate identity class. A separate key class must be
used when compound key includes an entity relationship field. We will see
shortly what discipline must be followed in definining this separate
identity class.
3. The mapping of
private Sculpture sculpture;
uses non-standard joins using a pair of join columns.
@JoinColumns({
@JoinColumn(name="sculpture_id",
referencedColumnName="sculpture_ID"),
@JoinColumn(name="locale", referencedColumnName="'en'")
})
The first join column is the 'standard' one -- it refers to the
primary key column of Sculpture's table.
The second join column is what makes it non-standard. This join column makes
the join condition from Sculpture to this entity its locale column.
4. The non-standard join column uses a constant value. The default
constant value is set to 'en'. The single quote around 'en' is significant
because this quote distinguishes it as a constant value of the column rather
than a column name.
5. The locale field is also declared as part of the primary key, this
will enable the mapping to put a compound primary key of the form in
'sculpture_i18n' table
PRIMARY KEY (`locale`,`sculpture_id`)
6. The compound key class
public static class CompoundId implements Serializable {
public int sculpture;
public String locale;
comprised of the two fields, their name must match the corresponding
@Id annotated fields. What about the type?
Here comes the special bit about using Entity relationship as primary
key field. The type in the key class is same as the type of the primary key
of the relation. So as Sculpture declares its primary key as
public class Sculpture {
@Id
@Column(name="sculpture_ID")
private int id;
The key class declares its 'sculpture' field's type as int.
Under these mapping OpenJPA will generate the target schema you have
specified in your original mail.
Now the runtime behavior:
The behavior we want is we will issue query or find() as usual, but the
result should fetch the description according to the current locale. But in
our mapping, we have set our constant join value to 'en' -- which will only
bring us English language description. How to change that constant join
value dynamically?
That requires some internal information on OpenJPA's architecture which
makes every metadata available to runtime application. For example, to get
to the foreign key column that is using constant join value and changing it
that is what we need to do:
// naviagate through metadata repository to the foreign key
ForeignKey fk =((FieldMapping)
((OpenJPAEntityManagerFactorySPI)OpenJPAPersistence.cast(emf))
.getConfiguration()
.getMetaDataRepositoryInstance()
.getCachedMetaData(Sculpture.class)
.getField("desc")
.getMappedByMetaData())
.getForeignKey();
// get its constant column and change its value
Locale locale = Locale.FRENCH;
fk.joinConstant(fk.getConstantColumns()[0],
locale.getLanguage());
When the constant value needs to be changed is a application decision -- but
the interesting point is this change will transparently impact any query or
find() that joins to Sculpture_i18n from Sculpture table.
http://n2.nabble.com/file/n527521/NonStandardJoin.zip NonStandardJoin.zip
I have attached a small zip that packs the classes t
Re: no state snapshot available on embedded mapping
Hi Marc, On Jul 14, 2008, at 8:37 AM, Marc Logemann wrote: and yes, for the record: i changed to build time enhancement and now embedded entities work. Still interessted in the "why" answer. Yeah, me too. The difference might be due to something in your classes being enhanced differently using one enhancement technique versus another. Could you please file a JIRA with the relevant detail? Thanks, Craig -- Marc Logemann blog http://logemannreloaded.blogspot.com privat http://www.logemann.org Am 14.07.2008 um 16:22 schrieb Pinaki Poddar: Hi, Are you using runtime enhancement with Java 5? If yes, the immediate workaround is to enhance the persistent classes at build-time. -- View this message in context: http://n2.nabble.com/no-state-snapshot-available-on-embedded-mapping-tp526616p527331.html Sent from the OpenJPA Users mailing list archive at Nabble.com. Craig L Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! smime.p7s Description: S/MIME cryptographic signature
Re: no state snapshot available on embedded mapping
and yes, for the record: i changed to build time enhancement and now embedded entities work. Still interessted in the "why" answer. -- Marc Logemann blog http://logemannreloaded.blogspot.com privat http://www.logemann.org Am 14.07.2008 um 16:22 schrieb Pinaki Poddar: Hi, Are you using runtime enhancement with Java 5? If yes, the immediate workaround is to enhance the persistent classes at build-time. -- View this message in context: http://n2.nabble.com/no-state-snapshot-available-on-embedded-mapping-tp526616p527331.html Sent from the OpenJPA Users mailing list archive at Nabble.com.
Re: no state snapshot available on embedded mapping
Hi, yes, i am using a spring-tomcat-weaver.jar in Tomcat6 (with Java5) to achieve JPA runtime enhancement via Spring. What do you mean with workaround? Should this work "normally" ? I was quite happy with runtime enhancement, would be sad to leave that path thx for infos -- Marc Logemann blog http://logemannreloaded.blogspot.com privat http://www.logemann.org Am 14.07.2008 um 16:22 schrieb Pinaki Poddar: Hi, Are you using runtime enhancement with Java 5? If yes, the immediate workaround is to enhance the persistent classes at build-time. -- View this message in context: http://n2.nabble.com/no-state-snapshot-available-on-embedded-mapping-tp526616p527331.html Sent from the OpenJPA Users mailing list archive at Nabble.com.
Re: no state snapshot available on embedded mapping
Hi, Are you using runtime enhancement with Java 5? If yes, the immediate workaround is to enhance the persistent classes at build-time. -- View this message in context: http://n2.nabble.com/no-state-snapshot-available-on-embedded-mapping-tp526616p527331.html Sent from the OpenJPA Users mailing list archive at Nabble.com.
Re: @ElementJoinColumn wrong documentation
Hi,
Thanks for pointing this out.
The doc should be:
@ElementJoinColumn(name="SUB_ID", referencedColumnName="ID")
instead of
@ElementJoinColumn(name="SUB_ID", target="ID")
corrected now.
Marc Logemann-3 wrote:
>
> Hi,
>
> in the docs there is something written with attribute ("target").
> Obviously this attribute doesnt exist. Do you guys mean
> "referencedColumnName" instead?
>
> I am little bit surprised that one-many foreign key mapping is not
> part of JPA1.
>
> --
> Marc Logemann
> blog http://logemannreloaded.blogspot.com
> privat http://www.logemann.org
>
>
>
>
>
--
View this message in context:
http://n2.nabble.com/%40ElementJoinColumn-wrong-documentation-tp473697p527268.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.
