Armin, If you need an additional field in indirection table you can't use
non-decomposed m:n relation.
ok To make this possible (OJB populate an additional timestamp column in
indirection table on insert) with non-decomposed m:n relation you have to modify/extend OJB. If each indirection table has a additional column TIME_STAMP you can modify the creation of m:n insert statement. In this case you have to implement your own SqlGenerator class (extend existing default and override #getInsertMNStatement) and MtoNBroker class (override insert methods)... this will be complicated.
If there is one method that eventually inserts i cannot imagine that it is really complicated. I will have a look at it. I dont need to update values because the creationdate is only relevant on inserts. I don't know an easy solution for your problem.
If the timeframe between two synchronization calls is greater then seconds and you don't need millisecond precision of timestamp values you can try to update the indirection table entries after OJB insert/update the entries. You can use plain SQL or you can define a persistence capable object for each indirection table and after insert/update you request all rows with empty timestamp column, set the timestamp and update the indirection table objects.
Let me tell you a little more about the plan and the context. I store all my OJB repository equivalent meta data in a model that is stored in the database itself and is just another bunch of tables that is also backed by OJB. I generate OJB repository files from it (and also hibernate). When i am finished working at home, where i have no internet, i export my database and import it at work. When somebody else at work also updates the meta model in the meantime i am in trouble. So it should right now basically be a meta data versioning system. Time frames between synq actions will span hours if not days. I plan to use plain SQL, really simple just loop all tables and records and check their last modified date (lastmodified i can control from my code). It is the M2M stuff that only needs creationdate because they represent structure not data. The M2M records are present or they are removed, nothing else. I think you provided me with the answer, all i need is a creation stamp in the composed m2m relations. I will give that a shot and let you know how it works out. Cheers and a nice weekend to all, Dennis
