Am Montag, den 20.03.2006, 13:18 -0800 schrieb Satheesh Bandaram: > Hi Matthias, > > Matthias Ohlemeyer wrote: > > Hi, > > > > I've been trying to port a relatively complex application from Oracle to > > Derby for quite a while now, but it seems like I've hit a road block > > now. > > > > Can somebody explain the following behaviour? I copied the following > > input-output sequence from ij: > >
> I can help, if you promise to share our experience of porting your > application from Oracle to Derby. :-) Most certainly! I'm glad to share my experiences - I'm not so sure you will like what I think I found or how I judge my findings. Quite a while back I thought that it would be really neat to have an open source ERP package with an embedded open source database: Compiere on Derby.I took the approach of using the Compiere Database Kit to create a new port. This means that the Oracle-centric SQL-statements spread throughout the application remain unchanged in the code and a conversion algorithm has to mangle the statements to create SQL that is syntactically correct for the target db and semantically equivalent to the original statement. At first I created a some suitable conversion methods, then I realised (much too late!) that the approach would never work in all situations, so that I ended up with over 100 patches to the original Compiere code. In many of these cases one could argue if it is a result of a Derby "limitation" or a result of Compiere's Oracle-centric SQL-usage - I'll let others decide. Fact is, that I have Compiere Rel. 2.5.3b up and running - untested and with some known and most certainly many unknown limitations. Then I hit the error that sparked this thread. One might understand, why my assessment of the question if Derby is ready to run an ERP application has changed since then. It was my intention to create a Sourceforge project for the code, right now I'm not sure if this is the right thing to do, because I know, that some financial calculations will be wrong. (Actually I'm not quite ready to post the code because I would have to clean up a bit and would have to mark my changes - this is quite some work which just now I'm not ready to invest.) Maybe this sounds too negative, but I guess that's how it goes when you think you are really close and have to give up. There are certainly many things to like about Derby and it is absolutely not my intention to criticise this open source project. I hear the OS mantra "It's all about scratching your own itch" - only this time I can't, because it does not fit my goals. When I started out, I hoped to create an easy to install, ERP package, that could be used in POS situations, i.e. I wanted to concentrate on the business side of things, not on the technical side. > What kind of issues you faced and how easy or difficult was it etc... This would be part of one ore more different threads, wouldn't it? As I said: There is nothing to hide and I'll gladly share my thoughts (though time restrictions will probably make subsequent posts more concise!). Waiting for suggestions on how to proceed (in case you are interested at all and have not fallen asleep). One other remark: There was news that Compiere would do a Derby port on their own and that there is an agreement with some Derby developers to help them. This came after I was half way through. So far I have not seen any activity on this subject on any of the Derby lists. Is there some ongoing work I am not aware of? Quote: ""We're working together with the Derby development team and we'll provide a complete open source solution based on Derby and Cloudscape in six to nine months," said Jorg Janke, the company's founder and president, speaking at the Solutions Linux conference in Paris" See: http://www.networkworld.com/news/2006/013106-compiere.html Just a side note: There are other projects out there with similar goals but different approaches, e.g. http://www.knowledgesuccess.com (Compiere on hsqldb; they seem to have the policy to rather change the database behaviour before patching Compiere and seem to make some good progress. Another one is CODAF http://www.daffodildb.com/daffodil-compiere.html (They seem to be ready for production, but not completely open source; maybe this has changed.) So long Matthias > > CREATE TABLE t (d1 DOUBLE, d2 DOUBLE, n1 NUMERIC(31,11), n2 > > NUMERIC(31,11)); > > INSERT INTO t VALUES (1.5, 2.5, 1.5, 2.5); > > SELECT d1/d2, n1/n2, n1*(1.0/n2) FROM t; > > > > 1 |2 |3 > > > > ---------------------------------------------------------------- > > 0.6 |0 |0.600000000000000000000000000000 > > > > 1 row selected > > > This seems like a simple bug, at the first look. If you look at > NumericTypeCompiler code, which calculates the scale and precision of > operation result type, the comments and the code doesn't seem to > match. (getScale() method) I would suggest filing a bug in JIRA. > > I can provide more help in resolving the issue. > > Satheesh > > NumericTypeCompiler.java > > else if (TypeCompiler.DIVIDE_OP.equals(operator)) > { > /* > ** Take max left scale + right precision - right scale + > 1, > ** or 4, whichever is biggest > */ > LanguageConnectionContext lcc = > (LanguageConnectionContext) > > (ContextService.getContext(LanguageConnectionContext.CONTEXT_ID)); > > // Scale: 31 - left precision + left scale - right scale > val = Math.max(NumberDataValue.MAX_DECIMAL_PRECISION_SCALE > - lprec + lscale - rscale, 0); > } > > Here val is returning zero for scale, it seems. >
