Compass provides two main features with JPA: Mirroring and Indexing.
Mirroring mirrors changes made through the JPA API into the search engine
(through lifecycle listeners), and Indexing allows to automatically index
all your database using both the JPA and Searchable classes. The indexing
I tried to open the entity manager before I get the ClassMetaData, but I
still get an empty array. Here is what I do:
OpenJPAEntityManagerFactory emf =
OpenJPAPersistence.cast(entityManagerFactory);
EntityManager entityManager = emf.createEntityManager();
entityManager.close();
ClassMetaData[]
-Original Message-
From: Patrick Linskey
Sent: Tuesday, January 02, 2007 1:44 AM
To: open-jpa-dev@incubator.apache.org
Subject: RE: Getting all the ClassMetaDatas
You may also be interested in the StateManager.getDirty()
method, which
returns a BitSet corresponding to the
[
http://issues.apache.org/jira/browse/OPENJPA-91?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anders Monrad updated OPENJPA-91:
-
I am using the type 4 driver, so there should not be any problems with native
code. I tried to add
I am trying to figure out how to configure OpenJPA to perform drop and then
create the db schema. I got as far as:
property name=openjpa.jdbc.SynchronizeMappings value=buildSchema /
Which causes the schema to be created, but does not drop it when the EMF
closes (or when a new EMF starts).
The
Shay-
Unfortunately, we don't have any automatic drop-table feature, but I
agree it would be handy (you might want to make a JIRA report with
the suggestion).
The only other recourse, I think, would be to just manually delete
the database files before running your tests.
On Jan 2,
Robert-
I completely agree. We usually just build all the tables once and
then just try to make sure all the objects are deleted at the end of
the test, but you are correct that this is sometimes more cumbersome
than it could be. An easy drop-then-create option would simplify
this,
Dain-
I assume you are specifying the ClassLoader by using your own
subclass of PersistenceUnitInfoImpl. OpenJPA should be using your
ClassLoader, although if the same class name is available in both
your classloader as well as the system classloader, then I think the
results are
For What It's Worth:
+1 on the drop-tables feature for OpenJPA. But I would caution
against using it on each test.
Sadly, my experience is that drop-create-tables is 99.9% of the time
taken in a typical test.
The JDO TCK runs hundreds of tests and we drop-create tables only on
demand.
Unfortunately, we don't have any automatic drop-table feature, but
I agree it would be handy (you might want to make a JIRA report
with the suggestion).
Note that the SynchronizeMappings property allows you to use all
the arguments of the mappingtool. So you can try something like:
Personally, I like to put both the data cleanup and data
initialization in the setUp() stage. It's sometimes a bit slower, but
if there is faulty cleanup logic in a previous test's tearDown(), it
may affect some random test down the road, and it can sometimes be
very difficult to track
On 1/2/07, Marc Prud'hommeaux [EMAIL PROTECTED] wrote:
Personally, I like to put both the data cleanup and data
initialization in the setUp() stage. It's sometimes a bit slower, but
if there is faulty cleanup logic in a previous test's tearDown(), it
may affect some random test down the road,
On 1/2/07, Craig L Russell [EMAIL PROTECTED] wrote:
For What It's Worth:
+1 on the drop-tables feature for OpenJPA. But I would caution
against using it on each test.
Sadly, my experience is that drop-create-tables is 99.9% of the time
taken in a typical test.
The JDO TCK runs hundreds of
[
http://issues.apache.org/jira/browse/OPENJPA-94?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12461839
]
Abe White commented on OPENJPA-94:
--
Note that the SynchronizeMappings property allows you to use all the
arguments
It is one of the first things I tried, I got this exception:
Caused by: org.apache.openjpa.lib.util.ParseException: There was an error
while setting up the configuration plugin option SynchronizeMappings. The
plugin was of type org.apache.openjpa.jdbc.meta.MappingTool. Setter
methods for the
Caused by: org.apache.openjpa.lib.util.ParseException: There was an
error
while setting up the configuration plugin option
SynchronizeMappings. The
plugin was of type org.apache.openjpa.jdbc.meta.MappingTool. Setter
methods for the following plugin properties were not available in
that
The way I usually do things is by starting a transaction, and simply rolling
it back when my test finishes (if it wasn't committed/rolled back during the
test method). This usually supports 90% of an application integration tests
needs. In my case, I have simple tests, I am running them against
Just using refresh does not clean up the data in the database
(getting Unique
constraints violations). Just for kicks I tried
SchemaTool.DropTables=true,
it did pass the configuration phase, but it still did not cleaned the
data/schema.
None of the options I mentioned are meant to clean up
Regarding getting dirty fields, Compass does not make use of it. When an
object changes, it must be completely reindexed by Compass (or deleted). In
my listeners, I simply get the source, and perform the appropriate operation
on Compass. It would be nice if Compass supported dirty fields, but it
I think so as well :)
Patrick Linskey wrote:
I think that Abe and Shay are talking about slightly different features.
-Patrick
--
Patrick Linskey
BEA Systems, Inc.
___
Notice: This email message, together with
[
http://issues.apache.org/jira/browse/OPENJPA-94?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12461857
]
Patrick Linskey commented on OPENJPA-94:
One downside of dropping and re-creating schemas is the latency of
Automatically clean that data without dropping the tables makes even more
sense. That would be a really cool feature.
Patrick Linskey wrote:
IMO, a more valuable option would be a way to delete all records in all
mapped tables, rather than doing unnecessary schema interrogation.
I still need to provide a classloader for this method. Another thing, I get
only the classes, where I need to ClassMetaData in order to check if it
extends another mapped class (in such cases I exclude it from the indexing
process since the select of the base class will return the derived classes
Hi,
Some experimenting with the @IdClass support is producing a strange
exception message when attempting to map an id field of type byte[].
According to the OpenJPA documentation, we need to use an Identity Class to
use byte[] as the id field type. Something like this:
@Entity
@IdClass
Kevin-
Also, this exception is supposedly only being produced with Oracle,
not
DB2. (I have not been able to verify that yet.) This would seem to
indicate that it's dictionary-specific, but I'm not seeing anything
there
yet...
Does Oracle even support blob primary keys? My recollection
Can you have java field of type byte[] that maps to a NUMERIC (or
heck a varchar) in he db? I'm guessing that Kevin's guid is a fixed
128 bit number. If it is and he can map it to a non-blob type, it
should be possible to join with any database system.
-dain
On Jan 2, 2007, at 3:09 PM,
You can use use RAW(16) to store GUIDs in Oracle. This datatype is
allowed in primary keys.
--
Regards,
Igor
Dain Sundstrom wrote:
Can you have java field of type byte[] that maps to a NUMERIC (or heck a
varchar) in he db? I'm guessing that Kevin's guid is a fixed 128 bit
number. If it is
Interesting ... sounds like a legit bug, then (although it bears
noting that byte[] primary keys aren't actually allowed by the JPA
spec, as per section 2.1.4 ... support for them is an OpenJPA
extension).
My guess is that this only affects Oracle, due to our special
handling of blobs.
You could do this with an @Externalizer that converts the byte[] into a
long or a string or what have you, and a @Factory that reverses it.
-Patrick
--
Patrick Linskey
BEA Systems, Inc.
___
Notice: This email message,
-Original Message-
From: Shay Banon [mailto:[EMAIL PROTECTED]
Sent: Tuesday, January 02, 2007 2:33 PM
To: open-jpa-dev@incubator.apache.org
Subject: RE: Perform automatic drop and create db schema
Automatically clean that data without dropping the tables
makes even more
[
https://issues.apache.org/jira/browse/OPENJPA-94?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12461899
]
Patrick Linskey commented on OPENJPA-94:
I added an optimization for MySQL with r492032, but disabled it by
The BrokerImpl class initializes the _loader to Thread.currentThread
().getContextClassLoader() when constructed (when an EM is
constructed). This cl is used while loading the mappings file. This
causes the entity classes to be loaded from the thread context class
loader instead of the
32 matches
Mail list logo
