d recipient,
> and have received this message in error, please immediately return this
> by email and then delete it.
>
>> -Original Message-
>> From: Shay Banon [mailto:[EMAIL PROTECTED]
>> Sent: Tuesday, January 02, 2007 12:34 AM
>> To: open-jpa-dev@incub
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.
>
> Addi
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, tog
opyrighted and/or
> legally privileged, and is intended solely for the use of the individual
> or entity named in this message. If you are not the intended recipient,
> and have received this message in error, please immediately return this
> by email and then delete it.
>
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.
Abe White wrote:
>
>> Caused by: org.apache.openjpa.lib.u
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 an
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
Issue Type: New Feature
Reporter: Shay Banon
Currently, in the persistence context, one can define:
Which causes OpenJPA to build the database schema based on the mapping defined.
Currently, there is no way to define it to drop tables if they exists before
creating the
> The only other recourse, I think, would be to just manually delete
> the database files before running your tests.
>
>
> On Jan 2, 2007, at 3:34 PM, Shay Banon wrote:
>
>>
>> I am trying to figure out how to configure OpenJPA to perform drop
>> an
I am trying to figure out how to configure OpenJPA to perform drop and then
create the db schema. I got as far as:
Which causes the schema to be created, but does not drop it when the EMF
closes (or when a new EMF starts).
The main reason I want it for is for simple tests, where each tests wor
;
> You might want to enable verbose logging and watch the make sure the
> class metadatas are registered before you try to get the list from
> the repository.
>
>
>
> On Jan 1, 2007, at 4:11 PM, Shay Banon wrote:
>
>>
>> Hi,
>>
>>Fir
prietary, copyrighted and/or
> legally privileged, and is intended solely for the use of the individual
> or entity named in this message. If you are not the intended recipient,
> and have received this message in error, please immediately return this
> by email and then delete it
; -Original Message-
>> From: Patrick Linskey
>> Sent: Monday, January 01, 2007 5:51 PM
>> To: open-jpa-dev@incubator.apache.org
>> Subject: RE: Getting all the ClassMetaDatas
>>
>> > -Original Message-
>> > From: Shay Banon [mailto:[EMAIL PR
Hi,
First, I hope that this is the correct forum for posting questions, so
sorry if it isn't.
I have an external list of classes that I would like to match against the
persistent classes that are defined/identified by OpenJPA. I would really
like to get the ClassMetaData for each one, since i
14 matches
Mail list logo
