Hi Andrew, I know I am a bit late with my answer to this problem, but I just have not been able to reply earlier.
First you are right that the intention of the clone method is to allow self-joins, i.e. the clone is an exact copy of the original with the exception of using a different table alias. Instead of using clone() you can simply create a second instance of the table that you need to self-join. MyTable t1 = new MyTable(db); MyTable t2 = new MyTable(db); Since in most cases where you need to self-join a table you have a corresponding foreign-key representing a self-reference I recommend creating a second instance with the database and make it accessible through a field or property. Although personally I prefer this approach from using clone(), of course clone() should work too. And indeed it looks like there is a problem when cloning the columns if they have been declared in a superclass. I will investigate this a bit further and fix this issue. Thanks, Rainer andrew cooke wrote: > re: Scala inter-op issue [Was: Importing XML] > > Hi, > > I just hit quite a serious issue for using Empire DB in Scala which I > thought I would flag, since you asked. > > The clone() method of DBTable (and perhaps any other clone method that > might be used) requires access to the attributes of an object (so that > it can copy columns). Unfortunately in Scala the attributes of an > instance are always private. It doesn't appear that way in Scala > code, because Scala automatically generates matching getters and > setters (that, simplifying slightly, have the same name as the > attribute - it sounds odd, but Scala has some unusual syntax that > makes it work). > > This means that cloning fails, because the private attribute generates > an illegal access exception. So any query that uses a table twice > (with different aliases) cannot be expressed in Empire DB (at least, I > assume this is solved by using DBTable.clone() - I have not yet got it > to work, for this reason). > > I can write my own clone function, I hope, once I learn some more > about Scala, or I can define my schema in Java. So this is not a > deal-breaker for me, but it would make using Empire DB from Scala much > simpler if the clone method either: > 1 - checked for the Scala syntax and used the Scala getters/setters > or > 2 - provided a separate method (cloneScala?) that used the Scala > getters/setters > > It is possible to make Scala objects conform to JavaBean standards, so > another solution would be to use setters that follow that convention, > but the code would be uglier in Scala and never used from Java, so I > don't think that is a good idea. > > Cheers, > Andrew > > > 2009/10/13 Francis De Brabandere <[email protected]>: > > Hi andrew, > > > > A bit offtopic. Do you use scala a lot? Do you think it is the future > > for java? Would there be a need for empire-db - scala integration > > code? > > > > Thanks, > > Francis > > > > On Tue, Oct 13, 2009 at 2:17 PM, andrew cooke <[email protected]> > wrote: > >> Sorry, no - my fault. I was using getRecordData instead of open. > Andrew > >> > >> 2009/10/13 andrew cooke <[email protected]>: > >>> Also, the dump is missing the first element of each table. I > believe > >>> that is a bug in Empire DB, but I will first try to reproduce it in > >>> Java and then file a report with a simple example. > >> > > > > > > > > -- > > http://www.somatik.be > > Microsoft gives you windows, Linux gives you the whole house. > >
