Yep - EMPIREDB-60. Andrew
2009/10/25 Francis De Brabandere <[email protected]>: > Do we have a Jira issue for this yet? > > On Sun, Oct 25, 2009 at 9:03 PM, Rainer Döbele <[email protected]> wrote: >> 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. >>> > >> > > > > -- > http://www.somatik.be > Microsoft gives you windows, Linux gives you the whole house. >
