Hi, Thanks - no problem with the delay, I have everything working perfectly at the moment (as far as I know) - I just subclassed DBTable to implement my own clone method.
Andrew 2009/10/25 Rainer Döbele <[email protected]>: > 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. >> > >
