Kevin,
Well, you didn't mention that you had a test case that proved
otherwise...
:-)
My fault sorry, working as advertised. (that is, if there is no active
transaction and the context is extended, then no error is thrown)
--
View this message in context:
I think if it sets a collection to null there may be a serious issue. On my
version 1.2.3_snapshot that comes with RAD 7.5.x, I have seen it happen that
even if I initialize a oneToMany (OTM) var to a collection, then it gets
set it to null when an existing entity is loaded. Much worse, any
I've seen a TransactionRequiredException error occur on persist() when no
transaction is active, for an extended persistence context. jsr220 states,
in 3.1.1:
/*
* @throws TransactionRequiredException if invoked on a
* container-managed entity manager of type
*
Kevin,
I can see that interpretation, but I'm not only going by the doc, it
actually seems to be doing that validation at persist() time and throwing
the TransactionRequiredException, even though the em is marked as
persistenceContextType.EXTENDED... so unless i'm missing something, it seems
as
I made some changes to tell OpenJPA to observe foreign key constraints. I
didn't do it with SynchronizeMappings because it is not crystal clear to me
exactly under what circumstances the MappingTool might ever make attempt to
make changes to the database. (I am in a strictly 'bottom-up'
I'm using 1.2.3_Snapshot (that comes with IBM RAD 7.5).
I'm having an issue with remove operation receiving an Optimistic Lock
exception.
My domain includes a structure which would be similar to a Department and
Employees. Thus:
All employees own a relationship to a Department
Employees
Is OSIV with a stateful EJB reliable? What happens, when under load (or
otherwise), the container decides to passivate the stateful bean. Would that
event be completely transparent to a conversation that is using the bean,
the PC, and managed entities therein?
The Seam project appears to
bump..
Since the OP I have observed that a CHAR(n) field is mapped to a string, it
may be padded OR trimmed, even on the same version of JPA (either JPA1.2.3
OR JPA2.0.2). The behavior appears to be by table. Eg in one table where the
column CHAR(2) the values come back padded:
'C '
'1 '
'X '
'B
correction - on JPA1.2.3 the field in both tables is padded. going to
JPA2.0.2, one is padded and one is trimmed.
--
View this message in context:
http://openjpa.208410.n2.nabble.com/Padding-of-CHAR-n-columns-with-trailing-spaces-tp6364510p6386967.html
Sent from the OpenJPA Users mailing list
It appears the JPA2.0.2 fails properly reparameterize or evict a cached
prepared SQL statement with a collection valued parameter (eg an IN clause),
when the parameter has a different number of elements.
When this occurs, a warning Parameter has a value which is not compatible
with the available
When a fixed-length CHAR column is mapped to a Java string, in JPA1.2.3 the
value does not contain trailing spaces. In JPA 2.0.2, the value is
blank-added to the length of column in the database (DB2 with JDBC Universal
driver). For example a column is defined as CHAR(5). The value M1C1 appears
as
OPENJPA 1.2.3Snapshot, Rad 7.5.5
I am having a problem that an assignment to a persistent field in an entity
with accesstype FIELD is being ignored in a ~detached~ entity. Eg,
@OneToMany
private List articleList /* = new ArrayList() */ ;
public List getArticleList(){
if (articleList !=
I need to deploy one Enterprise Application Repository (EAR) file across
multiple Websphere servers, eg a development,test,QA,and production server,
where the schema name varies depending on the server. This is actually a
legal or regulatory requirement - the EAR file deployed to production must
I have a model with nested OneToMany , e.g., a Department with a list of
Managers and a Manager with a list of Projects. They have the requiste four
MTO and OTM mappings. Both OTM mappings specify eager fetch and cascade.ALL.
There is referential integrity constraints on both relationships, eg
14 matches
Mail list logo
