Locking an object with lock mode WRITE failed
Hi,
I get:
[org.apache.ojb.odmg.TransactionImpl] ERROR: Locking obj
[EMAIL PROTECTED] with lock mode 4 failed
[Lcom.entersys.escds.interfaces.UserRole;
org.odmg.ClassNotPersistenceCapableException:
[Lcom.entersys.escds.interfaces.UserRole;
at org.apache.ojb.odmg.ObjectEnvelope.manage(Unknown Source)
at org.apache.ojb.odmg.ObjectEnvelope.(Unknown Source)
at org.apache.ojb.odmg.TransactionImpl.register(Unknown Source)
at org.apache.ojb.odmg.TransactionImpl.lock(Unknown Source)
at com.entersys.util.DAOHelper.update(DAOHelper.java:159)
at
com.entersys.escds.services.DAOSoapBindingImpl.updateUser(DAOSoapBindingImpl
.java:479)
when I attempt to lock an object that has an array property (1:n and
unidirectional)
What would be the problem? I don't want to use java.util.Collection, as my
User class will serialize/deserialize using SOAP
thanks
my code:
public Object update(Object data) throws Exception {
Transaction tx = odmg.newTransaction();
tx.begin();
try {
Object o = ((HasBroker) tx).getBroker().getObjectByQuery(new
QueryByIdentity(data));
tx.lock(o, Transaction.WRITE); <- throws the exception here
org.apache.commons.beanutils.PropertyUtils.copyProperties(o, data);
tx.commit();
}
catch (Throwable t) {
tx.abort();
throw new Exception(t.getMessage());
}
return data;
}
public class User implements java.io.Serializable {
private java.lang.String userId;
...
private com.entersys.escds.interfaces.UserRole[] userRoles;
public java.lang.String getUserId() {
return userId;
}
public void setUserId(java.lang.String userId) {
this.userId = userId;
}
...
public com.entersys.escds.interfaces.UserRole[] getUserRoles() {
return userRoles;
}
public void setUserRoles(com.entersys.escds.interfaces.UserRole[]
userRoles) {
this.userRoles = userRoles;
}
}
...
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
ojb returns empty collections instead of null
When I retrieve an object from the database via OJB which has a collection of child objects, but there are no child objects in the database, OJB fills the parent object collection reference with an empty collection instead of keeping the collection reference null. Is there a way to have OJB keep the reference null? Is there a benefit to having the empty collection as opposed to a null reference? -tim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
AW: OJB Scheme Generator
1. What database are you on 2. Which JDBC driver are you using 3. Which version of OJB 4. How does your database look like 5. What have you entered when asked for the catalog and schema regular expression. If you could send me this information I might be able to help you. regards, Florian > -Ursprungliche Nachricht- > Von: Emmanuel Dupont [mailto:[EMAIL PROTECTED] > Gesendet: Donnerstag, 27. Februar 2003 16:58 > An: 'OJB Users List' > Betreff: OJB Scheme Generator > > > I have a trouble with OJB Scheme Generator (\build reverse-db). > > > > I have a database and I want to generate the xml files and the java > objects. > > > > I connected to the database and nothing happens. > > > > I clicked on the "Read" button and I had these two questions : > > Enter regular expression to match catalogs > > Enter regular expression to match schemas > > > > With the result : > > I had the DBMeta treebox with nothing inside... > > > > > > What should I do ? I'm lost! > > > > Tx !! > > > > > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: OJB - JDO - deletePersistent
Thomas,
I assume this means that Version 1 should work too. Is there any chance
that you can try to fix this problem before OJB Release 2?
Thanks,
Sebastian
Mahler Thomas wrote:
Seems to be a buf in my code...
-Original Message-
From: Sebastian Thomschke [mailto:[EMAIL PROTECTED]
Sent: Thursday, February 27, 2003 9:44 PM
To: [EMAIL PROTECTED]
Subject: OJB - JDO - deletePersistent
The JDO tutorial uses the pm.getObjectById() method to get an
instance of a
product to delete it. Shouldn't it be possible to do the same via
pm.newQuery?
In my JDO test project I first tried it using the
pm.newQuery() method to
get a user object/record. Retrieving was fine, but when I try
to delete it,
OJB throws the following exception:
javax.jdo.JDOUserException: Instance of class
sebthom.jdotest.persistenceObjects.User is not
persistent.
at
com.sun.jdori.common.PersistenceManagerImpl.deletePersistentIn
ternal(PersistenceManagerImpl.java:1823)
at
com.sun.jdori.common.PersistenceManagerImpl.deletePersistent(P
ersistenceManagerImpl.java:739)
at
com.sun.jdori.common.PersistenceManagerWrapper.deletePersisten
t(PersistenceManagerWrapper.java:444)
at sebthom.jdotest.Main.run(Main.java:120)
at sebthom.jdotest.Main.main(Main.java:165)
Exception in thread "main"
When I use the pm.getObjectById() method it works fine.
What's wrong with
the way using pm.newQuery()?
Thanks in advance.
Regards,
Sebastian
==
// Version 1 using pm.newQuery()
tx = pm.currentTransaction();
tx.begin();
query = pm.newQuery(User.class, "id==" + 10);
result = (Collection) query.execute();
user = (User) result.iterator().next();
if (user == null)
{
System.out.println("did not find a matching instance...");
tx.rollback();
}
else
{
pm.deletePersistent(user);
tx.commit();
query.close(result);
}
//Version 2 using pm.getObjectById()
User example = new User();
example.setId(10);
Identity oid = new Identity(example);
User toBeDeleted = (User) pm.getObjectById(oid, false);
tx = pm.currentTransaction();
tx.begin();
pm.deletePersistent(toBeDeleted);
if (toBeDeleted == null)
{
System.out.println("did not find a matching instance...");
tx.rollback();
}
else
{
pm.deletePersistent(toBeDeleted);
tx.commit();
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: query formulation question
I have done more experimentation and found that my pseudo ODMG was actually quite close. The following ODMG query runs: select person from " + Person.class.getName() + " where roles.project.title != XXX" Unfortunately, this only returns persons that have at least one role. It doesn't return all the persons that have no roles. So I still don't quite know the answer to my original question. And this brings up another one: How would one formulate the query to return all persons that have no roles? As an incentive to get answers to these query formulation questions, I promise to write up a FAQ on what I learn. Will Phil Warrick wrote: Hi all, Does anyone have an answer for Will? I've often asked myself this same question. Or more generally how to deal with traversing towards the 'many' side of an association (1:m or n:m) in a query. Thanks, Phil Will Jaynes wrote: I'm wondering how to formulate a query. I'm sure this is s FAQ, but I can't find the answer... Looking at the "Mapping M:N associations" section of the "Advanced O/R" doc, I have a situation which is analogous to the Person, Project, PersonProject example of decomposition into two 1:N associations. I'd like to retrieve all Person objects that do not have a Project with title = "XXX". This seems kind of complicated since, if I were to write it in psuedo ODMG I would write select person from Person.class.getName() where roles[*].project.title != "XXX" How would this really be formulated in ODMG? How would this be formulated in just the PB? Thanks, Will - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: query formulation question
Hi all, Does anyone have an answer for Will? I've often asked myself this same question. Or more generally how to deal with traversing towards the 'many' side of an association (1:m or n:m) in a query. Thanks, Phil Will Jaynes wrote: I'm wondering how to formulate a query. I'm sure this is s FAQ, but I can't find the answer... Looking at the "Mapping M:N associations" section of the "Advanced O/R" doc, I have a situation which is analogous to the Person, Project, PersonProject example of decomposition into two 1:N associations. I'd like to retrieve all Person objects that do not have a Project with title = "XXX". This seems kind of complicated since, if I were to write it in psuedo ODMG I would write select person from Person.class.getName() where roles[*].project.title != "XXX" How would this really be formulated in ODMG? How would this be formulated in just the PB? Thanks, Will - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: OJB test failures
Hi again, > Not sure I fully understand yet the Identity change. > Sounds like you are saying internal state was inconsistent? No, don't misunderstand me I only made presumptions - begin a X-file ;-) I'm not very familiar with this part of OJB source (Jakob, Thomas and Matthew are the specialists for that stuff). regards, Armin - Original Message - From: "Andrew Gilbert" <[EMAIL PROTECTED]> To: "OJB Users List" <[EMAIL PROTECTED]>; "Armin Waibel" <[EMAIL PROTECTED]> Sent: Friday, February 28, 2003 9:43 PM Subject: RE: OJB test failures Armin, Thank you very much for this! I will build latest and re-test soon. The bummer is, it would be a major impediment to our use of OJB if we couldn't convert on pk fields. We use a custom GUID impl for the pk in many of our BO's and tables. Not sure I fully understand yet the Identity change. Sounds like you are saying internal state was inconsistent? > ## > I think the made changes are correct, because the conversion > was not transparent for the user of the Identity object. I suggest > never use converted (java --> sql) pk fields within Identity > (I don't know if code base is comply with this suggest, > maybe that's the reason for the hassle). > The conversion could be done when it's necessary. > But nevertheless I think there is a nasty bug when using > field conversion with pk fields. > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: OJB test failures
Armin, Thank you very much for this! I will build latest and re-test soon. The bummer is, it would be a major impediment to our use of OJB if we couldn't convert on pk fields. We use a custom GUID impl for the pk in many of our BO's and tables. Not sure I fully understand yet the Identity change. Sounds like you are saying internal state was inconsistent? > ## > I think the made changes are correct, because the conversion > was not transparent for the user of the Identity object. I suggest > never use converted (java --> sql) pk fields within Identity > (I don't know if code base is comply with this suggest, > maybe that's the reason for the hassle). > The conversion could be done when it's necessary. > But nevertheless I think there is a nasty bug when using > field conversion with pk fields. > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ODMG vs broker
Hi Yuji, Yuji Shinozaki wrote: Thomas, So in a given implementation, could you freely use a mix of ODMG or PersistenceBroker, given that you do not need auto-update or auto-delete? correct! Many users do this as PersistenceBroker queries are more flexible and even allow direct execution of SQL. cheers, thomas yuji On Fri, 28 Feb 2003, Thomas Mahler wrote: Hi Joerg, Joerg Lensing wrote: hi experts, i studied the junit-test to learn about mapping and querying. Although the documention says, the mapping can be used to both (ODMG(OQL-Queries) and PersistenceBroker) Yes that's still true. it seems to me, that there are differences. (e.g. org.apache.ojb.odmg.Article vs. org.apache.ojb.broker.Article) . Is there a general rule? There is only exception: The semantics for cascding updates and deletes is different in ODMG and PB. In ODMG you *must not* set auto-update="true" and also not auto-delete="true". This sole difference is documented in tutorial3. cheers, Thomas thanx joerg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Yuji Shinozaki Computer Systems Senior Engineer [EMAIL PROTECTED] Advanced Technologies Group (804)924-7171 Information Technology & Communication http://www.people.virginia.edu/~ys2nUniversity of Virginia - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: OJB test failures
Hi Andrew, - Original Message - From: "Andrew Gilbert" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Cc: "Armin Waibel" <[EMAIL PROTECTED]> Sent: Wednesday, February 26, 2003 10:25 PM Subject: OJB test failures Armin, Looks like the test case ConvertedKeyReferenceTest might be broken. Lines 69 and 90 test for pk of ConversionReferrer being converted. If you look at the repository_junit.xml the pk field for ConversionReferrer does not have a conversion attribute. ## ups! you are right, it's fixed in CVS. Thanks a lot! Also, neither ConvertedKeyReferenceTest nor FeildConversionForeigenKeyTest cover the case where key conversion is not happening for primary key for an object that is created. Think this was broken by change in rev 1.12 of Identity ## I think the made changes are correct, because the conversion was not transparent for the user of the Identity object. I suggest never use converted (java --> sql) pk fields within Identity (I don't know if code base is comply with this suggest, maybe that's the reason for the hassle). The conversion could be done when it's necessary. But nevertheless I think there is a nasty bug when using field conversion with pk fields. In ConvertedKeyReferenceTest there is a case covering this issue. Not sure why it dosen't pick up the failure, but one theory is the nature of the test. The class TestInt2IntConverter flip flops values. It might better to do destructive but predictable damage to the value, rather than a flip flop. Flip flop will only really detect failure to convert in one direction, not both! Another strategy to test might be to force a class cast exception if conversion doesn't occur. I do know I need to patch Identity for the normal case of CRUD for an object with a pk that requires conversion. What I don't know is what bad side effects this causes. I think cleaning up the test cases first would help to find out. I refactored and renamed all FieldConversion test cases and add a new (hope the last one) test case to test field conversion. See FieldConversionTest (new), FieldConversionTest_2 (ConvertedKeyReferenceTest), FieldConversionTest_3 (FieldConversionForeigenKeyTest). Feel free to check the made changes (4 eyes better than 2). Looking for input. If you think it is worthwhile, I can come up with a test for PK conversion that will detect bi-directional failure. Just uncertain what the scenario is for reliably testing double conversion. Not sure if the test in ConvertedKeyReferenceTest for this is correct. If you missing some specific test, feel free to change one of the tests and send me the files. I will check in the stuff ASAP. As well all fixes ;-) regards, Armin Finally, would be nice to rename the file FieldConversionForeigenKeyTest to FieldConversionForeignKeyTest. It is mispelled. Let me know what you think. Will be glad to tackle this if you like. Index: Identity.java === RCS file: /home/cvspublic/db-ojb/src/java/org/apache/ojb/broker/Identity.java,v retrieving revision 1.14 diff -r1.14 Identity.java 195,196c195 < // BRJ: do not convertToSql < this.pkValues = targetBroker.serviceBrokerHelper().getKeyValues(cld, objectToIdentitify,false); --- > this.pkValues = targetBroker.serviceBrokerHelper().getKeyValues(cld, objectToIdentitify); > -Original Message- > From: Armin Waibel [mailto:[EMAIL PROTECTED] > Sent: Wednesday, February 19, 2003 6:32 AM > To: OJB Developers List > Subject: [OJB test failures] some really nasty bugs > > > Hi all, > > I add some new test cases posted by Users (thanks Charles, Oliver and > all I forget) > and do some modifications to point out the problems (I hope so;-)). > > 1. UserTestCases > Test testImplicitLocking() fail when implicit locking was set to > 'false', > the test pass when implicit locking was 'true'. > The test change the 'useImplicitLocking' property to 'false' > to simulate the situation. > > 2. FieldConversionForeignKeyTest/ConvertedKeyReferenceTest > This was the really nasty bug! > Both test cases use field conversions. It seems that in some cases > PK fields are not converted. > > For example in StatementManager#bindSelect(...) method, the given > Identity object seems to wrap unconverted pk values, when I do a > field conversion in this method all seems ok, but now in some cases > the field conversion was done twice (ConvertedKeyReferenceTest) > on the same values. This is tragic when using a field conversion > like TestIntToIntConverter. > > I think one part of the problem could be Identity, because it is > possible to make Identity instances with converted pk values > and without! > new Identity(Object objectToIdentitify, PersistenceBroker > targetBroker) > --> without conversion > new Identity(Class aClass, Object[] CONVERTEDpkValues) > --> with converted pk valuse > > Any suggestions? > > regards, > Armin > > > ---
Re: ODMG vs broker
Thomas, So in a given implementation, could you freely use a mix of ODMG or PersistenceBroker, given that you do not need auto-update or auto-delete? yuji On Fri, 28 Feb 2003, Thomas Mahler wrote: > Hi Joerg, > > Joerg Lensing wrote: > > hi experts, > > i studied the junit-test to learn about mapping and querying. Although > > the documention says, the mapping can be used to both (ODMG(OQL-Queries) > > and PersistenceBroker) > > Yes that's still true. > > > it seems to me, that there are differences. (e.g. > > org.apache.ojb.odmg.Article vs. org.apache.ojb.broker.Article) . Is > > there a general rule? > > There is only exception: The semantics for cascding updates and deletes > is different in ODMG and PB. > In ODMG you *must not* set auto-update="true" and also not > auto-delete="true". > This sole difference is documented in tutorial3. > > cheers, > Thomas > > > > > thanx > > > > joerg > > > > > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > Yuji Shinozaki Computer Systems Senior Engineer [EMAIL PROTECTED] Advanced Technologies Group (804)924-7171 Information Technology & Communication http://www.people.virginia.edu/~ys2nUniversity of Virginia - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ODMG vs broker
Hi Joerg, Joerg Lensing wrote: hi experts, i studied the junit-test to learn about mapping and querying. Although the documention says, the mapping can be used to both (ODMG(OQL-Queries) and PersistenceBroker) Yes that's still true. it seems to me, that there are differences. (e.g. org.apache.ojb.odmg.Article vs. org.apache.ojb.broker.Article) . Is there a general rule? There is only exception: The semantics for cascding updates and deletes is different in ODMG and PB. In ODMG you *must not* set auto-update="true" and also not auto-delete="true". This sole difference is documented in tutorial3. cheers, Thomas thanx joerg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: OJB Clobbers Default Values with Null
Hi Shannon, Shannon Ewing wrote: I think that should be a temp fix until something better can be done. What really is needed is a flag in the repository that can optionally be added to a column definition that indicates not to send this column on an insert (and update too?) if there is no value. I agree! I I'm currently thinking of adding support for such a solution. It won't be difficult to implement. But as always I like to design it elegantly and this needs some inspiration (and even more transpiration ;-). cheers, Thomas "CF" problem is similar to the one we have. Ours deals with OJB putting a value into our primary key fields on insert when the value is auto-generated by the database (in this case MS SQL Server). We could not use the "normal" way OJB deals with this issue because our database does not support the concept of general sequence key generation like Oracle, SAP DB, PostgreSQL, etc. Our fix was to hack the two classes that deal with the generation and population of insert statements to not include that column. Not good but necessary for us. So, the best solution that would not only resolve our issue but also "CF", would be to simply be able to flag the column to not be included in inserts if there is no value. -Original Message- From: Mahler Thomas [mailto:[EMAIL PROTECTED] Sent: Friday, February 28, 2003 2:23 AM To: 'OJB Users List' Subject: RE: OJB Clobbers Default Values with Null Hi again, Hello, Way back in OJB 0.9.7 I brought this issue up and I don't think I got much response. I took an OJB hiatus for a while and now I'm back and have run up against this problem again. The problem is that when I insert a record, OJB tries to insert null values into fields that I did not explicity set in my object. So if I have specified default values in my database field, which I do quite a bit, those default default values never get used because the query that OJB generates is telling the database to explicitly set those fields to null instead of omitting those fields and letting the db handle it. I find it really hard to believe that I'm the only one that has issues with this... but I don't see much discussion on it. Am I missing something obvious or does anybody have any good workarounds (besided implementing default values on the application/bean side) or has it been addressed in 0.9.9? This is still not addressed in 0.9.9 and later! You can avoid writing to db columns by not providing a field-descriptor for the attribute in question. You could either change an existing class-descriptor at runtime, to add/remove field-descriptors, or use different repositories for read and write phases. cheers, Thomas Thanks! - Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, and more - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] +-+ This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. +-+ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Brrow broker from pool is failing : OptimisticLockException in PB Api
yes! you are right. I already did that and started workingalthough I have no idea why it is working and what difference I made. I thought it is a valid config. Can't think about the possible cause? any idea. Anyway, thanks a lot for your help. -Original Message- From: Armin Waibel [mailto:[EMAIL PROTECTED] Sent: Fri 2/28/2003 9:29 AM To: OJB Users List; Ajitesh Das Cc: Subject: Re: Brrow broker from pool is failing : OptimisticLockException in PB Api Hi, that's (not?) really strange! But I think it could be a little problematic to set an autoincrement, primary key field (zonaDbId) as the locking field (locking="true") of the persistent object. Try to use a separate field to do optimistic locking. regards, Armin - Original Message - From: "Ajitesh Das" <[EMAIL PROTECTED]> To: "OJB Users List" <[EMAIL PROTECTED]> Sent: Wednesday, February 26, 2003 6:09 PM Subject: RE: Brrow broker from pool is failing : OptimisticLockException in PB Api > Here is my class descriptor: > class="com.acme.ZonaSample" > table="ZONA_TABLE" > > > name="zonaDbId" > column="ID" > jdbc-type="INTEGER" > primarykey="true" > nullable="false" > indexed="true" > autoincrement="true" > locking="true" > default-fetch="false" > /> > name="attr1" > column="a1" > jdbc-type="BIGINT" > primarykey="false" > nullable="true" > indexed="true" > autoincrement="false" > locking="false" > default-fetch="false" > /> > name="attr2" > column="a2" > jdbc-type="INTEGER" > primarykey="false" > nullable="true" > indexed="true" > autoincrement="false" > locking="false" > default-fetch="false" > /> > name="attr3" > column="a3" > jdbc-type="BIGINT" > primarykey="false" > nullable="true" > indexed="true" > autoincrement="false" > locking="false" > default-fetch="false" > /> > > > > -Original Message- > From: Armin Waibel [mailto:[EMAIL PROTECTED] > Sent: Wed 2/26/2003 2:50 AM > To: OJB Users List > Cc: > Subject: Re: Brrow broker from pool is failing : OptimisticLockException in PB Api > > > > Hi, > > need some more info. > Please send the class-descriptor of > your 'persistentObject' > > regards, > Armin > > - Original Message - > From: "Ajitesh Das" <[EMAIL PROTECTED]> > To: "OJB Users List Armin Waibel" > <[EMAIL PROTECTED]@code-au-lait.de>; "OJB Users List" > <[EMAIL PROTECTED]> > Sent: Wednesday, February 26, 2003 11:34 AM > Subject: RE: Brrow broker from pool is failing : OptimisticLockException > in PB Api > > > > Hi Armin : > > Thanks for your reply. > > >first, it seems that you mix the JDO-api with the PB-api in your code > > >PersistenceManager --> JDO > > >PersistenceBroker (PB), PersistenceBrokerFactory (PBF)--> PB-api > > >maybe a typo. > > yes this is a Typo. I am just playing PB api > > > > > I get this "Brrow broker from pool is failing" exception after some > > >success write. > > >Think you forget to call the close method of the PB after use. > > >PB.close() returns > > >the broker to broker pool managed by PBF. > > > > > > Here are the tries I have made : > > > > case 1* If I put PB.close() ... I get exception saying > "OprimisticLockException: Some body using the object" > > > > case 2* If I do not use PB.close() I ran out of Broker pool. > > > > here is the structure I am using > > > > Loop : > > > >< condition> > > > >new PersistentObject() > > >
Re: What is current status of LOBs with Oracle?
You will find a patch in the archives that works with Oracle OCI driver. The patch does not appear to work for lobs > 4000 with the Oracle thin driver. - Original Message - From: "Chris Rossi" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Friday, February 28, 2003 8:45 AM Subject: What is current status of LOBs with Oracle? > Hello, > > I remember having seen previously conversation on this list concerning > getting OJB to be able to work with LOBs in Oracle. I remember there > being some philosophical debate on how best to attack this problem, and > I remember that some people had patched their own code to get this to > work, but there hadn't been any decision as to what to do to the current > codebase. > > My apologies if this has already been addressed and I just lost it in > the volume of email, but I'm wondering now, has this been resolved? Or > are LOBs under Oracle still broken? Does anybody have a patch they > would share that works for OJB 0.9.9? > > At any rate, I've hit a point where the ability to do LOBs in Oracle is > a basic requirement. If I can't do it with OJB then I'm going to have > to do it with something else. > > rossi > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Brrow broker from pool is failing : OptimisticLockException in PB Api
Hi, that's (not?) really strange! But I think it could be a little problematic to set an autoincrement, primary key field (zonaDbId) as the locking field (locking="true") of the persistent object. Try to use a separate field to do optimistic locking. regards, Armin - Original Message - From: "Ajitesh Das" <[EMAIL PROTECTED]> To: "OJB Users List" <[EMAIL PROTECTED]> Sent: Wednesday, February 26, 2003 6:09 PM Subject: RE: Brrow broker from pool is failing : OptimisticLockException in PB Api > Here is my class descriptor: > class="com.acme.ZonaSample" > table="ZONA_TABLE" > > > name="zonaDbId" > column="ID" > jdbc-type="INTEGER" > primarykey="true" > nullable="false" > indexed="true" > autoincrement="true" > locking="true" > default-fetch="false" > /> > name="attr1" > column="a1" > jdbc-type="BIGINT" > primarykey="false" > nullable="true" > indexed="true" > autoincrement="false" > locking="false" > default-fetch="false" > /> > name="attr2" > column="a2" > jdbc-type="INTEGER" > primarykey="false" > nullable="true" > indexed="true" > autoincrement="false" > locking="false" > default-fetch="false" > /> > name="attr3" > column="a3" > jdbc-type="BIGINT" > primarykey="false" > nullable="true" > indexed="true" > autoincrement="false" > locking="false" > default-fetch="false" > /> > > > > -Original Message- > From: Armin Waibel [mailto:[EMAIL PROTECTED] > Sent: Wed 2/26/2003 2:50 AM > To: OJB Users List > Cc: > Subject: Re: Brrow broker from pool is failing : OptimisticLockException in PB Api > > > > Hi, > > need some more info. > Please send the class-descriptor of > your 'persistentObject' > > regards, > Armin > > - Original Message - > From: "Ajitesh Das" <[EMAIL PROTECTED]> > To: "OJB Users List Armin Waibel" > <[EMAIL PROTECTED]@code-au-lait.de>; "OJB Users List" > <[EMAIL PROTECTED]> > Sent: Wednesday, February 26, 2003 11:34 AM > Subject: RE: Brrow broker from pool is failing : OptimisticLockException > in PB Api > > > > Hi Armin : > > Thanks for your reply. > > >first, it seems that you mix the JDO-api with the PB-api in your code > > >PersistenceManager --> JDO > > >PersistenceBroker (PB), PersistenceBrokerFactory (PBF)--> PB-api > > >maybe a typo. > > yes this is a Typo. I am just playing PB api > > > > > I get this "Brrow broker from pool is failing" exception after some > > >success write. > > >Think you forget to call the close method of the PB after use. > > >PB.close() returns > > >the broker to broker pool managed by PBF. > > > > > > Here are the tries I have made : > > > > case 1* If I put PB.close() ... I get exception saying > "OprimisticLockException: Some body using the object" > > > > case 2* If I do not use PB.close() I ran out of Broker pool. > > > > here is the structure I am using > > > > Loop : > > > >< condition> > > > >new PersistentObject() > > > > set values; > > > > PB = PersistenceBrokerFactory.defaultPersistenceBroker(); > > > > PB.beginTx(); > > > > PB.store(myObj) > > > > PB.commitTx() > > > > PB.close() // tried with and without this > > > > > > I have also tried with a static var ...holding obj reference of PB > during my application initialization. > > > > I am still getting Optimistic Lock Exception similar to case 2. > > > > thanks > > > > ~ajitesh > > > > > > > > > > > > - Original Message - > > From: "Ajitesh Das" <[EMAIL PROTECTED]> > > To: "OJB Users List" <[EMAIL PROTECTED]>; "OJB Users List" > > <[EMAIL PROTECTED]>; "OJB Users List" <[EMAIL PROTECTED]>; > > "OJB Users List" <[EMAIL PROTECTED]> > > Sent: Wednesday, February 26, 2003 10:45 AM > > Subject: Brrow broker from pool is failing : OptimisticLockException > in > > PB Api > > > > > > > * Here is my issue : > > > - When I save the "Broker" object reference in a static > > variable and use that in multiple context > > > I get Optimistic Lock exception. > > > - If I do not save the Broker object reference : > > > // pm = PersistenceManager.getInstance(); // return > > Broker.defaultPersistenceBroker() > > > pm = PersistenceBrokerFactory.defaultPersistenceBroker(); > > > > > > I get this "Brrow broker from pool is failing" exception after some > > success write. I need to import a big data set into db table from a > CSV > > file and I make this in a *big* loop. > > > > > > Please advise. > > > > > > = > > > java.util.NoSuchElementException > > > at
Re: How does one CRUD a M:N relationship. Any solid examples of CRUD! CRUD! CRUD! CRUD!
Update. I think I have this figured out. The problem I encountered was
caused by forgotten to add in code to initialize my Vector upon creation and
was receiving a nullPointerException during use.
Dah!
Jeff
On Thursday 27 February 2003 01:41 pm, you wrote:
> Hi,
>
> I've setup a non-decomposed M:N relationship in my datastore so now how do
> I CRUD (create, read, update and delete) records that participate in this
> relationship? An example provided by the OJB website for adding records to
> datastore does exist but doesn't reflect any type of advanced relationship
> between tables. How would one modify this example to reflect a M:N
> relationship? What I'm really looking for CRUD!!! I want CRUD! Yummy
> CRUD! Okay, I'm being silly... Any help would be appreciated.
>
> *** Simple example CUT FROM PersistenceBroker API documentation ***
> public void apply()
> {
> // this will be our new object
> Product newProduct = new Product();
> // now read in all relevant information and fill the new object:
> System.out.println("please enter a new product");
> String in = readLineWithMessage("enter name:");
> newProduct.setName(in);
> in = readLineWithMessage("enter price:");
> newProduct.setPrice(Double.parseDouble(in));
> in = readLineWithMessage("enter available stock:");
> newProduct.setStock(Integer.parseInt(in));
>
> // now perform persistence operations
> try
> {
> // 1. open transaction
> broker.beginTransaction();
>
> // 2. make the new object persistent
> broker.store(newProduct);
> broker.commitTransaction();
> }
> catch (PersistenceBrokerException ex)
> {
> // if something went wrong: rollback
> broker.abortTransaction();
> System.out.println(ex.getMessage());
> ex.printStackTrace();
> }
> }
>
>
> Thanks in advance,
>
> Jeff
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Criteria - SUBQUERY
hi marian, subqueries work in ojb with one drawback: ist's not yet possible to refer to an attribute in the enclosing query. hth jakob Marian Skalsky wrote: Hello! 1) Is there a way how to construct the Criteria object (to avoid usage of DIRECT SQL) that will perform SELECT from SELECT in the 0.9.7 API? 2) There is "addIn(java.lang.String attribute, Query subQuery)" in the 0.9.9 API.. that is, if I don't miss, the solution for subqueries.. right? 3) Is this subquery feature working properly ? No problems reported ? Thx a lot! $kala. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
What is current status of LOBs with Oracle?
Hello, I remember having seen previously conversation on this list concerning getting OJB to be able to work with LOBs in Oracle. I remember there being some philosophical debate on how best to attack this problem, and I remember that some people had patched their own code to get this to work, but there hadn't been any decision as to what to do to the current codebase. My apologies if this has already been addressed and I just lost it in the volume of email, but I'm wondering now, has this been resolved? Or are LOBs under Oracle still broken? Does anybody have a patch they would share that works for OJB 0.9.9? At any rate, I've hit a point where the ability to do LOBs in Oracle is a basic requirement. If I can't do it with OJB then I'm going to have to do it with something else. rossi - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Limiting a number of rows returned
hi max,
anyone is invited to contribute...
jakob
Max Vesely wrote:
Thanks, Scott.
Would database implementation be the right place for this code?
If yes, is anyone working on it?
If not, Can someone like me contribute to OJB framework?
Thank, you.
Max.
-Original Message-
From: Scott Howlett [mailto:[EMAIL PROTECTED]
Sent: Wednesday, February 26, 2003 10:30 PM
To: OJB Users List
Subject: RE: Limiting a number of rows returned
I implemented this functionality for PostgreSQL.
I subclassed SqlGeneratorDefaultImpl to provide the functionality and then
pointed to my subclass in OJB.properties.
My OJB.properties entry is:
SqlGeneratorClass=PostgreSqlStatementGenerator
My subclass code is:
import org.apache.ojb.broker.accesslayer.sql.SqlGeneratorDefaultImpl;
import org.apache.ojb.broker.metadata.ClassDescriptor;
import org.apache.ojb.broker.platforms.Platform;
import org.apache.ojb.broker.query.Query;
public class PostgreSqlStatementGenerator extends SqlGeneratorDefaultImpl {
public SqlStatementGenerator(Platform pf) {
super(pf);
}
public String getPreparedSelectStatement(
Query query,
ClassDescriptor cld) {
String result = super.getPreparedSelectStatement(query, cld);
return addOffsetLimit(query, result);
}
public String getSelectStatementDep(Query query, ClassDescriptor
cld) {
String result = super.getSelectStatementDep(query, cld);
return addOffsetLimit(query, result);
}
private String addOffsetLimit(Query q, String stmt) {
int startIndex = q.getStartAtIndex();
int endIndex = q.getEndAtIndex();
if (endIndex > 0) {
if (startIndex < 0 || startIndex >= endIndex) {
startIndex = 0;
}
stmt += " LIMIT " + (endIndex - startIndex);
}
if (startIndex > 0) {
stmt += " OFFSET " + startIndex;
}
return stmt;
}
}
Hope that helps,
Scott Howlett
-Original Message-
From: Max Vesely [mailto:[EMAIL PROTECTED]
Sent: Wednesday, February 26, 2003 10:27 PM
To: [EMAIL PROTECTED]
Subject: Limiting a number of rows returned
Hi,
Does anyone know how to limit a number of rows returned from database
using OJB?
Most of the database engines implement custom keywords to limit a number of
rows for select statement (top, limit, rownum () < .), OJB Query
interface has methods in it to set EndAt and StartAt indexes as well as the
size of resultset returned but setting them doesn't really help. The
database engine I'm using is HSQLDB.
Thank, you in advance.
Max.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: OJB Clobbers Default Values with Null
We have the same behavior here, our DBA sure doesn't like it, along with the putting in '0' for integer fields instead of null :) Ryan -Original Message- From: Shannon Ewing [mailto:[EMAIL PROTECTED] Sent: Friday, February 28, 2003 8:47 AM To: 'OJB Users List' Subject: RE: OJB Clobbers Default Values with Null I think that should be a temp fix until something better can be done. What really is needed is a flag in the repository that can optionally be added to a column definition that indicates not to send this column on an insert (and update too?) if there is no value. "CF" problem is similar to the one we have. Ours deals with OJB putting a value into our primary key fields on insert when the value is auto-generated by the database (in this case MS SQL Server). We could not use the "normal" way OJB deals with this issue because our database does not support the concept of general sequence key generation like Oracle, SAP DB, PostgreSQL, etc. Our fix was to hack the two classes that deal with the generation and population of insert statements to not include that column. Not good but necessary for us. So, the best solution that would not only resolve our issue but also "CF", would be to simply be able to flag the column to not be included in inserts if there is no value. -Original Message- From: Mahler Thomas [mailto:[EMAIL PROTECTED] Sent: Friday, February 28, 2003 2:23 AM To: 'OJB Users List' Subject: RE: OJB Clobbers Default Values with Null Hi again, > > Hello, > > Way back in OJB 0.9.7 I brought this issue up and I don't > think I got much response. I took an OJB hiatus for a while > and now I'm back and have run up against this problem again. > The problem is that when I insert a record, OJB tries to > insert null values into fields that I did not explicity set > in my object. So if I have specified default values in my > database field, which I do quite a bit, those default default > values never get used because the query that OJB generates is > telling the database to explicitly set those fields to null > instead of omitting those fields and letting the db handle it. > > I find it really hard to believe that I'm the only one that > has issues with this... but I don't see much discussion on > it. Am I missing something obvious or does anybody have any > good workarounds (besided implementing default values on the > application/bean side) or has it been addressed in 0.9.9? This is still not addressed in 0.9.9 and later! You can avoid writing to db columns by not providing a field-descriptor for the attribute in question. You could either change an existing class-descriptor at runtime, to add/remove field-descriptors, or use different repositories for read and write phases. cheers, Thomas > > Thanks! > > > > - > Do you Yahoo!? > Yahoo! Tax Center - forms, calculators, tips, and more > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] +-+ This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. +-+ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Help Needed For A Complex Query
Hi Steven, Yes OJB does support sub-select queries but - as you say - it isn't very efficient. Furthermore, I have to join the results of this query to results of another similair query via a many-many indirection table - in other words, the full query is far more complex than the example given. What I've done for now is to do a direct SQL query, but use "equals" instead of joins as in the following. SELECT PARENT.* FROM ACCOUNTTYPE , ACCOUNTTYPE AS PARENT WHERE PARENT.baseCode =ACCOUNTTYPE.baseCode AND (ACCOUNTTYPE.ID = 3) Like your solution, this too is db-neutral but I suspect more efficient than the subquery. Thanks for the suggestion, though. Cheers, Charles. >-Original Message- >From: Ebersole, Steven [mailto:[EMAIL PROTECTED] >Sent: 28 February 2003 15:36 >To: 'OJB Users List' >Subject: RE: Help Needed For A Complex Query > > >I thought OJB supported IN sub-select queries? Still new to >it, so I am not >sure, but I thought I remembered seeing comments about it on >the mailing >list. > >If so, you could rewrite this query as: >SELECT * >FROM ACCOUNTTYPE >WHERE baseCode IN (SELECT baseCode FROM ACCOUNTTYPE WHERE ID = 3) > > >Not (usually) as effecient as a join, but completely db-nuetral... > > > >|-Original Message- >|From: Charles Anthony [mailto:[EMAIL PROTECTED] >|Sent: Friday, February 28, 2003 2:49 AM >|To: '[EMAIL PROTECTED]' >|Subject: Help Needed For A Complex Query >| >| >|Hi All, >| >|I need to do a "self-join", on 'relationships' that are >|not defined in my >|repository.xml. Is this possible, and if so how ? >| >|Here is a very much simplified version of what I want to >|do. Here's a sample >|of the table (the class is very similar) >| >|Table ACCOUNTTYPE >|id, baseCode, variationCode >|1, "A", null >|2, "A", "B" >|3, "A", "C" >|4, "B", null >|5, "B", "A" >|6, "B", "B" >|7, "B", "C" >| >|I want to find all account types that have the same >baseCode as the >|accountType with an id of 3. i.e. I want to return >|accounttypes 1,2,3 >| >|In SQL I would do : >|SELECT PARENT.* >| FROM ACCOUNTTYPE >| INNER JOIN ACCOUNTTYPE PARENT ON ACCOUNTTYPE.baseCode = >|PARENT.baseCode >|WHERE (ACCOUNTTYPE.ID = 3) >| >|Can I do the same in a PB Query ? Failing that, in an OQL query ? >| >|I realise I can drop "down" to a SQL query, if I have to, >|but I'd really >|rather not if possible - our app must be completely >|cross-db compatible, and >|join's syntaxes vary across DBs. >| >|Oh, and the repository.xml cannot really be modified to >include new >|relationships (it is automatically generated from XDE by a >|process we wrote, >|and I don't want to have to manually 'fix' it each tim) >| >|Am I asking for the impossible ? >| >|Thanks, >| >|Charles. >| >| >|This email and any attachments are strictly confidential >|and are intended >|solely for the addressee. If you are not the intended >|recipient you must >|not disclose, forward, copy or take any action in reliance >|on this message >|or its attachments. If you have received this email in >|error please notify >|the sender as soon as possible and delete it from your >|computer systems. >|Any views or opinions presented are solely those of the >|author and do not >|necessarily reflect those of HPD Software Limited or its >|affiliates. >| >| At present the integrity of email across the internet >|cannot be guaranteed >|and messages sent via this medium are potentially at risk. >| All liability >|is excluded to the extent permitted by law for any claims >|arising as a re- >|sult of the use of this medium to transmit information by or to >|HPD Software Limited or its affiliates. >| >| >| >|--- >|-- >|To unsubscribe, e-mail: [EMAIL PROTECTED] >|For additional commands, e-mail: [EMAIL PROTECTED] >| > >- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] > This email and any attachments are strictly confidential and are intended solely for the addressee. If you are not the intended recipient you must not disclose, forward, copy or take any action in reliance on this message or its attachments. If you have received this email in error please notify the sender as soon as possible and delete it from your computer systems. Any views or opinions presented are solely those of the author and do not necessarily reflect those of HPD Software Limited or its affiliates. At present the integrity of email across the internet cannot be guaranteed and messages sent via this medium are poten
RE: Help Needed For A Complex Query
I thought OJB supported IN sub-select queries? Still new to it, so I am not sure, but I thought I remembered seeing comments about it on the mailing list. If so, you could rewrite this query as: SELECT * FROM ACCOUNTTYPE WHERE baseCode IN (SELECT baseCode FROM ACCOUNTTYPE WHERE ID = 3) Not (usually) as effecient as a join, but completely db-nuetral... |-Original Message- |From: Charles Anthony [mailto:[EMAIL PROTECTED] |Sent: Friday, February 28, 2003 2:49 AM |To: '[EMAIL PROTECTED]' |Subject: Help Needed For A Complex Query | | |Hi All, | |I need to do a "self-join", on 'relationships' that are |not defined in my |repository.xml. Is this possible, and if so how ? | |Here is a very much simplified version of what I want to |do. Here's a sample |of the table (the class is very similar) | |Table ACCOUNTTYPE |id, baseCode, variationCode |1, "A", null |2, "A", "B" |3, "A", "C" |4, "B", null |5, "B", "A" |6, "B", "B" |7, "B", "C" | |I want to find all account types that have the same baseCode as the |accountType with an id of 3. i.e. I want to return |accounttypes 1,2,3 | |In SQL I would do : |SELECT PARENT.* | FROM ACCOUNTTYPE | INNER JOIN ACCOUNTTYPE PARENT ON ACCOUNTTYPE.baseCode = |PARENT.baseCode |WHERE (ACCOUNTTYPE.ID = 3) | |Can I do the same in a PB Query ? Failing that, in an OQL query ? | |I realise I can drop "down" to a SQL query, if I have to, |but I'd really |rather not if possible - our app must be completely |cross-db compatible, and |join's syntaxes vary across DBs. | |Oh, and the repository.xml cannot really be modified to include new |relationships (it is automatically generated from XDE by a |process we wrote, |and I don't want to have to manually 'fix' it each tim) | |Am I asking for the impossible ? | |Thanks, | |Charles. | | |This email and any attachments are strictly confidential |and are intended |solely for the addressee. If you are not the intended |recipient you must |not disclose, forward, copy or take any action in reliance |on this message |or its attachments. If you have received this email in |error please notify |the sender as soon as possible and delete it from your |computer systems. |Any views or opinions presented are solely those of the |author and do not |necessarily reflect those of HPD Software Limited or its |affiliates. | | At present the integrity of email across the internet |cannot be guaranteed |and messages sent via this medium are potentially at risk. | All liability |is excluded to the extent permitted by law for any claims |arising as a re- |sult of the use of this medium to transmit information by or to |HPD Software Limited or its affiliates. | | | |--- |-- |To unsubscribe, e-mail: [EMAIL PROTECTED] |For additional commands, e-mail: [EMAIL PROTECTED] | - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: OJB Clobbers Default Values with Null
I think that should be a temp fix until something better can be done. What really is needed is a flag in the repository that can optionally be added to a column definition that indicates not to send this column on an insert (and update too?) if there is no value. "CF" problem is similar to the one we have. Ours deals with OJB putting a value into our primary key fields on insert when the value is auto-generated by the database (in this case MS SQL Server). We could not use the "normal" way OJB deals with this issue because our database does not support the concept of general sequence key generation like Oracle, SAP DB, PostgreSQL, etc. Our fix was to hack the two classes that deal with the generation and population of insert statements to not include that column. Not good but necessary for us. So, the best solution that would not only resolve our issue but also "CF", would be to simply be able to flag the column to not be included in inserts if there is no value. -Original Message- From: Mahler Thomas [mailto:[EMAIL PROTECTED] Sent: Friday, February 28, 2003 2:23 AM To: 'OJB Users List' Subject: RE: OJB Clobbers Default Values with Null Hi again, > > Hello, > > Way back in OJB 0.9.7 I brought this issue up and I don't > think I got much response. I took an OJB hiatus for a while > and now I'm back and have run up against this problem again. > The problem is that when I insert a record, OJB tries to > insert null values into fields that I did not explicity set > in my object. So if I have specified default values in my > database field, which I do quite a bit, those default default > values never get used because the query that OJB generates is > telling the database to explicitly set those fields to null > instead of omitting those fields and letting the db handle it. > > I find it really hard to believe that I'm the only one that > has issues with this... but I don't see much discussion on > it. Am I missing something obvious or does anybody have any > good workarounds (besided implementing default values on the > application/bean side) or has it been addressed in 0.9.9? This is still not addressed in 0.9.9 and later! You can avoid writing to db columns by not providing a field-descriptor for the attribute in question. You could either change an existing class-descriptor at runtime, to add/remove field-descriptors, or use different repositories for read and write phases. cheers, Thomas > > Thanks! > > > > - > Do you Yahoo!? > Yahoo! Tax Center - forms, calculators, tips, and more > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] +-+ This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. +-+ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
using the same column for primary and foreign key
Hi,
When using OJB, is it possible in a 1:1 relationship to have the primary and
foreign keys the same? For example, I have a MEMBERS table and a
MEMBER_BANK_DETAILS table. The primary key in both is MEMBER_CAE_NUMBER. I
explicitly set this value in both member objects and add a reference to the
bank details object in the member object. When I try to store the member
object I get the error below. The relevent mappings are also shown.
Thanks,
John
.
.
.
.
java.sql.SQLException: ORA-01400: cannot insert NULL into
("MCPS_TEST"."MEMBERS"."MEMBER_CAE_NUMBER")
at oracle.jdbc.dbaccess.DBError.throwSqlException(DBError.java:169)
at oracle.jdbc.ttc7.TTIoer.processError(TTIoer.java:208)at
oracle.jdbc.ttc7.Oall7.receive(Oall7.java:543) at
oracle.jdbc.ttc7.TTC7Protocol.doOall7(TTC7Protocol.java:1405)[org.apache.ojb
.broker.accesslayer.JdbcAccessImpl] ERROR: SQLException during the execution
of the insert (for a ie.mcps.member.model.MemberModel): ORA-01400: cannot
insert NULL into ("MCPS_TEST"."MEMBERS"."MEMBER_CAE_NUMBER")
ORA-01400: cannot insert NULL into
("MCPS_TEST"."MEMBERS"."MEMBER_CAE_NUMBER")
at
oracle.jdbc.ttc7.TTC7Protocol.parseExecuteFetch(TTC7Protocol.java:822) at
oracle.jdbc.driver.OracleStatement.executeNonQuery(OracleStatement.java:1602
) at
oracle.jdbc.driver.OracleStatement.doExecuteOther(OracleStatement.java:1527)
at
oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStatement.java
:2045) at
oracle.jdbc.driver.OraclePreparedStatement.executeUpdate(OraclePreparedState
ment.java:395) at
com.p6spy.engine.logging.P6LogPreparedStatement.executeUpdate(P6LogPreparedS
tatement.java:182) at
org.apache.ojb.broker.accesslayer.JdbcAccessImpl.executeInsert(JdbcAccessImp
l.java:199) at
org.apache.ojb.broker.singlevm.PersistenceBrokerImpl.storeToDb(PersistenceBr
okerImpl.java:1742) at
org.apache.ojb.broker.singlevm.PersistenceBrokerImpl.store(PersistenceBroker
Impl.java:1683) at
org.apache.ojb.broker.singlevm.PersistenceBrokerImpl.store(PersistenceBroker
Impl.java:632) at
org.apache.ojb.broker.singlevm.DelegatingPersistenceBroker.store(DelegatingP
ersistenceBroker.java:151) at
ie.mcps.member.dao.MemberDAO.addMember(MemberDAO.java:54) at
ie.mcps.member.dao.TestMemberDAO.testAddMember(TestMemberDAO.java:197) at
java.lang.reflect.Method.invoke(Native Method) at
junit.framework.TestCase.runTest(TestCase.java:166) at
junit.framework.TestCase.runBare(TestCase.java:140) at
junit.framework.TestResult$1.protect(TestResult.java:106) at
junit.framework.TestResult.runProtected(TestResult.java:124)at
junit.framework.TestResult.run(TestResult.java:109) at
junit.framework.TestCase.run(TestCase.java:131) at
junit.framework.TestSuite.runTest(TestSuite.java:173) at
junit.framework.TestSuite.run(TestSuite.java:168) at
com.borland.jbuilder.unittest.JBTestRunner.run(JBTestRunner.java:161) at
com.borland.jbuilder.unittest.JBTestRunner.initiateTest(JBTestRunner.java:19
4) at
com.borland.jbuilder.unittest.JBTestRunner.main(JBTestRunner.java:486) 516
[main] FATAL ie.mcps.member.dao.MemberDAO - Exception thrown while adding
Member. Message: ORA-01400: cannot insert NULL into
("MCPS_TEST"."MEMBERS"."MEMBER_CAE_NUMBER")
-Original Message-
From: Joerg Lensing [mailto:[EMAIL PROTECTED]
Sent: 28 February 2003 11:43
To: OJB Users List
Subject: ODMG vs broker
hi experts,
i studied the junit-test to learn about mapping and querying. Although
the documention says, the mapping can be used to both (ODMG(OQL-Queries)
and PersistenceBroker)
it seems to me, that there are differences. (e.g.
org.apache.ojb.odmg.Article vs. org.apache.ojb.broker.Article) . Is
there a general rule?
thanx
joerg
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
This e-mail and any files transmitted with it are confidential and may be
privileged and are intended solely for the individual named/ for the use of
the individual or entity to whom they are addressed.If you are not the
intended addressee, you should not disseminate, distribute or copy this
e-mail.Please notify the sender immediately if you have received this e-mail
by mistake and delete this e-mail from your system.If you are not the
intended recipient, you are notified that reviewing, disclosing, copying,
distributing or taking any action in reliance on the contents of this e-mail
is strictly prohibited.Please note that any views or opinions expressed in
this e-mail are solely those of the author and do not necessarily represent
those of Traventec Limited.E-mail transmission cannot be guaranteed to be
secure or error-free as information could be intercepted, corr
ODMG vs broker
hi experts, i studied the junit-test to learn about mapping and querying. Although the documention says, the mapping can be used to both (ODMG(OQL-Queries) and PersistenceBroker) it seems to me, that there are differences. (e.g. org.apache.ojb.odmg.Article vs. org.apache.ojb.broker.Article) . Is there a general rule? thanx joerg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[reverse-db] regular expressions (was: reverse-db)
Hi, you can put POSIX regular expressions in these input dialogs to filter for certain catalogs and schemas. If you do not want to filter or do not feel comfortable with regex, just leave these fields blank. A blank regular expression will match any string, so you will not filter anything. If you want to reverse engineer an Oracle database, it might be a good idea to leave the catalog regex blank (Oracle doesn't know the concept of catalogs) and fill the name of the schema the tables are in (ie. the name of the user who owns the tables). That way you will save a lot of time, especially with large oracle databases, where reading can take its time. regards, Florian > -Ursprüngliche Nachricht- > Von: Emmanuel Dupont [mailto:[EMAIL PROTECTED] > Gesendet: Donnerstag, 27. Februar 2003 18:26 > An: 'OJB Users List' > Betreff: RE : RE : RE : reverse-db > > > Sorry, > > It still doesn't work. Is there any Mysql incompatibilities ? > > Reverse-db2 shows meall my tables but it can't generate xml mapping > yet.. > > Any idea ? > > > > -Message d'origine- > De : Robert S. Sfeir [mailto:[EMAIL PROTECTED] > Envoyé : jeudi 27 février 2003 17:37 > À : OJB Users List > Objet : Re: RE : RE : reverse-db > > If I remember right, the first popup put the name of your db, the > second leave blank. If that doesn't work flip the info, blank first db > name second. > > On Thursday, Feb 27, 2003, at 11:41 US/Eastern, Emmanuel Dupont wrote: > > > Mysql with "mysql-connector-java-3.0.6-stable" jdbc driver. > > > > > > > > I don't manage to see my database tables in the window > > > > What can I do ? > > > > > > > > -Message d'origine- > > De : Ebersole, Steven [mailto:[EMAIL PROTECTED] > > Envoyé : jeudi 27 février 2003 17:30 > > À : 'OJB Users List' > > Objet : RE: RE : reverse-db > > > > I never even got to that point. The catalogs and schema entries would > > be > > for RDBMSs supporting those concepts. What database are you using? > > > > > > |-Original Message- > > |From: Emmanuel Dupont > > |[mailto:[EMAIL PROTECTED] > > |Sent: Thursday, February 27, 2003 10:37 AM > > |To: 'OJB Users List' > > |Subject: RE : reverse-db > > | > > | > > |I have the same trouble but my database is not large. > > | > > |In fact I didn't' understood what I have to put in the fields : > > | > > |Enter regular expression to match catalogs > > | > > |Enter regular expression to match schemas > > | > > |What did you put ? > > | > > | > > |-Message d'origine- > > |De : Ebersole, Steven [mailto:[EMAIL PROTECTED] > > |Envoyé : jeudi 27 février 2003 17:17 > > |À : OJB Users List (E-mail) > > |Objet : reverse-db > > | > > |I have a pretty large database which a need to map, and > > |was hoping to use > > |the reverse-db tool to at least get an initial working copy. > > | > > |So I launch the tool, and connect to my database fine. > > |However, as soon as > > |I hit "read" (which I believe is the next step), the generator > > just > > |hangs/locks. Not sure if it is taking so long because the > > |schema is so > > |large or if there is really a problem. Is there a way to > > |enable logging > > |from the tool? Or has anyone experienced this before? > > | > > | > > | > > |Steve Ebersole > > |IT Integration Engineer > > |Vignette Corporation > > |Office: 512.741.4195 > > |Mobile: 512.297.5438 > > | > > |Visit http://www.vignette.com > > | > > |--- > > |-- > > |To unsubscribe, e-mail: [EMAIL PROTECTED] > > |For additional commands, e-mail: [EMAIL PROTECTED] > > | > > | > > |--- > > |-- > > |To unsubscribe, e-mail: [EMAIL PROTECTED] > > |For additional commands, e-mail: [EMAIL PROTECTED] > > | > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Help Needed For A Complex Query
Hi, you have the same problem i'am having. You need to be able to use multiple aliases on the same table in a query. Therefore you need to be able to assign 'aliases' to criteria objects (using the PB API) and so telling them to use the same alias in their respictive where-clauses. In your example, one criteria uses no alias and the other uses 'PARENT'. Currently OJB does not support this. I myself use OJB 0.9.7 and patched it so it supports this feature. I send this path to Jakob Braeuchi so he can have a look at it and i am hoping it will be integrated in the next release. Roger Janssen iBanx B.V * The information contained in this communication is confidential and is intended solely for the use of the individual or entity to whom it is addressed.You should not copy, disclose or distribute this communication without the authority of iBanx bv. iBanx bv is neither liable for the proper and complete transmission of the information has been maintained nor that the communication is free of viruses, interceptions or interference. If you are not the intended recipient of this communication please return the communication to the sender and delete and destroy all copies. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: How does one CRUD a M:N relationship. Any solid examples of CRUD! CRUD! CRUD! CRUD!
I am not sure I understand what you want to know,
but I think you mean: how to create or remove a n:m relationship
between two objects. I have some questions about that also,
maybe one of the guru's could shed some light on this.
Our application is using these MtoN relations with success,
and I am very pleased with most of the things in OJB.
[But we only use the PB API, no experience with ODMG or JDO, and
version 0.9.5 (preparing the move to 0.9.9)]
For example we have such a bidirectional relationship between
user objects and group objects, where a user can be in many groups
(and groups can have many users).
The relationship is mapped on a table that you create, with two columns
f.i. columns id_user and id_group. But you do not directly access this table,
instead you have two collections, f.i. user.groups and group.users, as
defined in de repository.xml mapping table.
To create a relation you insert a user instance in the group.users collection,
with normal Java code. And then you persist the group. This is done via
persistence broker store. This will cause the collection to be scanned,
and the relationship table will be filled. And before it is filled,
the existing relations are deleted (to make room for the (re)creation of the
relations :->)
No the problem with this is, as far as I can see, that you do not really
have CRUD on the relationbship table. It all goes automagically.
So if the collection is big, then all its relations will be dropped,
and then rebuilt, which is not always the most efficient thing to do.
And the OJB cache also has to be taken care of (this may have been
improved in versions after 0.9.5). That is, the user.groups collection
will not automatically be updated, so you have to make sure that you
do not store that instance without updating its collection, or else
you will undo the new relationships and restore the old. The way we
solve this is by updating both the objects (using an application method
called "link (obj_a, obj_b, collection_field_name_a, collection_field_name_b)"
[the collections are both updated, and both objects are stored]
and also removing the cached instances from the OJB cache.
However, this does seem to be quite an inefficient operation. I am sure we are
doing something wrong here, or at least doing something suboptimal.
So as far as I know, these "automagic" MtoN collections are great
for retrieval (the certainly are nice in combination with collection proxies),
but can be a pain to maintain. I would really like to hear others about
their experiences.
Regards,
Theo
> Van: Jeffrey Gilbert [mailto:[EMAIL PROTECTED]
> Verzonden: donderdag 27 februari 2003 22:41
> Aan: [EMAIL PROTECTED]
> Onderwerp: How does one CRUD a M:N relationship. Any solid examples of
> CRUD! CRUD! CRUD! CRUD!
>
>
> Hi,
>
> I've setup a non-decomposed M:N relationship in my datastore so now how do I
> CRUD (create, read, update and delete) records that participate in this
> relationship? An example provided by the OJB website for adding records to
> datastore does exist but doesn't reflect any type of advanced relationship
> between tables. How would one modify this example to reflect a M:N
> relationship? What I'm really looking for CRUD!!! I want CRUD! Yummy CRUD!
> Okay, I'm being silly... Any help would be appreciated.
>
> *** Simple example CUT FROM PersistenceBroker API documentation ***
> public void apply()
> {
> // this will be our new object
> Product newProduct = new Product();
> // now read in all relevant information and fill the new object:
> System.out.println("please enter a new product");
> String in = readLineWithMessage("enter name:");
> newProduct.setName(in);
> in = readLineWithMessage("enter price:");
> newProduct.setPrice(Double.parseDouble(in));
> in = readLineWithMessage("enter available stock:");
> newProduct.setStock(Integer.parseInt(in));
>
> // now perform persistence operations
> try
> {
> // 1. open transaction
> broker.beginTransaction();
>
> // 2. make the new object persistent
> broker.store(newProduct);
> broker.commitTransaction();
> }
> catch (PersistenceBrokerException ex)
> {
> // if something went wrong: rollback
> broker.abortTransaction();
> System.out.println(ex.getMessage());
> ex.printStackTrace();
> }
> }
>
>
> Thanks in advance,
>
> Jeff
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Help Needed For A Complex Query
Hi All, I need to do a "self-join", on 'relationships' that are not defined in my repository.xml. Is this possible, and if so how ? Here is a very much simplified version of what I want to do. Here's a sample of the table (the class is very similar) Table ACCOUNTTYPE id, baseCode, variationCode 1, "A", null 2, "A", "B" 3, "A", "C" 4, "B", null 5, "B", "A" 6, "B", "B" 7, "B", "C" I want to find all account types that have the same baseCode as the accountType with an id of 3. i.e. I want to return accounttypes 1,2,3 In SQL I would do : SELECT PARENT.* FROM ACCOUNTTYPE INNER JOIN ACCOUNTTYPE PARENT ON ACCOUNTTYPE.baseCode = PARENT.baseCode WHERE (ACCOUNTTYPE.ID = 3) Can I do the same in a PB Query ? Failing that, in an OQL query ? I realise I can drop "down" to a SQL query, if I have to, but I'd really rather not if possible - our app must be completely cross-db compatible, and join's syntaxes vary across DBs. Oh, and the repository.xml cannot really be modified to include new relationships (it is automatically generated from XDE by a process we wrote, and I don't want to have to manually 'fix' it each tim) Am I asking for the impossible ? Thanks, Charles. This email and any attachments are strictly confidential and are intended solely for the addressee. If you are not the intended recipient you must not disclose, forward, copy or take any action in reliance on this message or its attachments. If you have received this email in error please notify the sender as soon as possible and delete it from your computer systems. Any views or opinions presented are solely those of the author and do not necessarily reflect those of HPD Software Limited or its affiliates. At present the integrity of email across the internet cannot be guaranteed and messages sent via this medium are potentially at risk. All liability is excluded to the extent permitted by law for any claims arising as a re- sult of the use of this medium to transmit information by or to HPD Software Limited or its affiliates. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: long transactions
Hi again Phil, Great, your patch is doing exactly what I had in mind! The only thing missing (you mentioned it already) is detection of removed references. These won't handled properly. So the real thing would keep the original envelope.getObject() in the envelope and merge all changes from the objectToRegister into it. During this merge you can detect - all things that remain unchanged - all things modified - all things to be deleted the ObjectEnvelopes of the respective item must be marked accordingly to perform the right actions on commit. cheers, Thomas > -Original Message- > From: Phil Warrick [mailto:[EMAIL PROTECTED] > Sent: Thursday, February 27, 2003 8:54 PM > To: OJB Users List > Subject: Re: long transactions > > > Hi again, > > >> Right, write conflicts are detected with OL. But will there be an > >> efficient merge of the updated graph? > > > > > > No. > > > >> Say only one of the graph's n objects was modified. Is > OJB's use of > >> its cache going to compare the before/after status of each graph > >> object and perform a db update on only the one truly > changed object? > >> > > > > The PB does not track object state. > > > > In ODMG there is a mechanism that tracks the object state during a > > transaction. > > Have a look at the ObjectEnvelope class. > > This mechanism could be modified with moderate effort to > perform the > > "swizzling" you'd like to see. > > > > > >> Are we close to being a FAQ item? > >> > > > > I'd prefer a real solution instead of faq item :-) > > I did modify the behaviour of the ObjectEnvelopeTable to do > what I think > that you are suggesting (at the time I could not conjugate > the verb "to > swizzle"). See > > http://archives.apache.org/eyebrowse/ReadMsg?listName=ojb-user @jakarta.apache.org&msgNo=4682 Is this something like what you had in mind? Could this be generally useful? I'd be happy to extend/modify it to fit in as best possible, but I'd need some feedback. Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Criteria - SUBQUERY
Hello! 1) Is there a way how to construct the Criteria object (to avoid usage of DIRECT SQL) that will perform SELECT from SELECT in the 0.9.7 API? 2) There is "addIn(java.lang.String attribute, Query subQuery)" in the 0.9.9 API.. that is, if I don't miss, the solution for subqueries.. right? 3) Is this subquery feature working properly ? No problems reported ? Thx a lot! $kala. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: OJB Clobbers Default Values with Null
Hi again, > > Hello, > > Way back in OJB 0.9.7 I brought this issue up and I don't > think I got much response. I took an OJB hiatus for a while > and now I'm back and have run up against this problem again. > The problem is that when I insert a record, OJB tries to > insert null values into fields that I did not explicity set > in my object. So if I have specified default values in my > database field, which I do quite a bit, those default default > values never get used because the query that OJB generates is > telling the database to explicitly set those fields to null > instead of omitting those fields and letting the db handle it. > > I find it really hard to believe that I'm the only one that > has issues with this... but I don't see much discussion on > it. Am I missing something obvious or does anybody have any > good workarounds (besided implementing default values on the > application/bean side) or has it been addressed in 0.9.9? This is still not addressed in 0.9.9 and later! You can avoid writing to db columns by not providing a field-descriptor for the attribute in question. You could either change an existing class-descriptor at runtime, to add/remove field-descriptors, or use different repositories for read and write phases. cheers, Thomas > > Thanks! > > > > - > Do you Yahoo!? > Yahoo! Tax Center - forms, calculators, tips, and more > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: OJB - JDO - deletePersistent
Seems to be a buf in my code...
> -Original Message-
> From: Sebastian Thomschke [mailto:[EMAIL PROTECTED]
> Sent: Thursday, February 27, 2003 9:44 PM
> To: [EMAIL PROTECTED]
> Subject: OJB - JDO - deletePersistent
>
>
> The JDO tutorial uses the pm.getObjectById() method to get an
> instance of a
> product to delete it. Shouldn't it be possible to do the same via
> pm.newQuery?
> In my JDO test project I first tried it using the
> pm.newQuery() method to
> get a user object/record. Retrieving was fine, but when I try
> to delete it,
> OJB throws the following exception:
> javax.jdo.JDOUserException: Instance of class
> sebthom.jdotest.persistenceObjects.User is not
> persistent.
> at
> com.sun.jdori.common.PersistenceManagerImpl.deletePersistentIn
> ternal(PersistenceManagerImpl.java:1823)
> at
> com.sun.jdori.common.PersistenceManagerImpl.deletePersistent(P
> ersistenceManagerImpl.java:739)
> at
> com.sun.jdori.common.PersistenceManagerWrapper.deletePersisten
> t(PersistenceManagerWrapper.java:444)
> at sebthom.jdotest.Main.run(Main.java:120)
> at sebthom.jdotest.Main.main(Main.java:165)
> Exception in thread "main"
>
> When I use the pm.getObjectById() method it works fine.
> What's wrong with
> the way using pm.newQuery()?
>
> Thanks in advance.
>
> Regards,
> Sebastian
>
> ==
>
> // Version 1 using pm.newQuery()
> tx = pm.currentTransaction();
> tx.begin();
> query = pm.newQuery(User.class, "id==" + 10);
> result = (Collection) query.execute();
> user = (User) result.iterator().next();
> if (user == null)
> {
> System.out.println("did not find a matching instance...");
> tx.rollback();
> }
> else
> {
> pm.deletePersistent(user);
> tx.commit();
> query.close(result);
> }
>
> //Version 2 using pm.getObjectById()
> User example = new User();
> example.setId(10);
> Identity oid = new Identity(example);
> User toBeDeleted = (User) pm.getObjectById(oid, false);
>
> tx = pm.currentTransaction();
> tx.begin();
> pm.deletePersistent(toBeDeleted);
> if (toBeDeleted == null)
> {
>System.out.println("did not find a matching instance...");
>tx.rollback();
> }
> else
> {
>pm.deletePersistent(toBeDeleted);
>tx.commit();
> }
>
> --
> +++ GMX - Mail, Messaging & more http://www.gmx.net +++
> Bitte lächeln! Fotogalerie online mit GMX ohne eigene Homepage!
>
>
>
> --
> +++ GMX - Mail, Messaging & more http://www.gmx.net +++
> Bitte lächeln! Fotogalerie online mit GMX ohne eigene Homepage!
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
