Re: [Libreoffice] [REVIEW] Oracle Report Builder corrupting chart objects

Michael, Others,

In our Compagny, editing house, we uses OO and LO as the one and only 
application. Base is here used as a frontend for getting data out of 
flat-text-datbases and MySQL. Data we need to produce documents  in 
Writer, Calc etc... For producing reports we found ORB pretty stable, so 
please keep LO-Base-ORB at least at the current OO level
Thanks

Fernand
> Hi Kohei,
>
> On Mon, 2011-05-16 at 22:14 -0400, Kohei Yoshida wrote:
> > 1. Promote the chart8 filter as the preferred filter for the
> > chart2.Document type.  This can be done by the attached
> > chart8-is-preferred-for-chart-document.diff patch.
>         Patch looks great to me :-) can we get that into -3-4 and get some more
> reviews for -3-4-0 ?
>
> > 2. Remove the type detection definition for the chart2.Document type
> > from the report builder itself.  This can be done by the
> > report-builder-dont-act-like-chart-handler.diff patch.  This will
> > prevent ORB from advertising itself as the chart filter provider.
>         Did you manage to play with the ORB chart feature ? I would strongly
> prefer a potential, transient breakage there, than an ODF
> incompatibility that will create broken files when we save ;-)
>
> > I think option 1 is pretty safe, but I don't really know if this would
> > cause any side effect in other, unexpected places.  For instance, the
> > latest ORB seems to claim some limited charting functionality, and this
> > may mess that up, or perhaps it may not.
>         Well - it sounds like the ORB is pretty messy anyway :-) so ... can it
> really make it much worse if it crashes the whole app left and right ?
>
> > My preferred option is option 3.  Because, while I was test-driving ORB,
> > it crashed several times due to null pointer exception from the Java
> > code.  And when it does that, it takes the whole soffice process down
> > with it.
>         And for those complaining about the idea of removing ORB altogether:
> doing some work to help out improve the stability of the implementation
> sounds like it would be a good plan. Rather than just wishing it was
> better, we need (new) developer resource applying to fixing it, with a
> set of clearly filed and isolated bug reports - preferably with the Java
> stack-frames that can come from the console (I think), and so on. If the
> functionality is extremely sub-standard, and creates the risk of
> data-loss for its users, then we may well want to disable it - or make
> it 'experimental'. "just reverting a commit" is not an easy thing to do
> - it requires first finding the problematic commit, also there are a lot
> of interlocking pieces in most such piles of software :-) so again, real
> developer resource is required: that can be grown out of sweat&  tears
> from technical QA guys digging deeper - or preferably from interest from
> those who most need / use the feature.
>
>         ATB,
>
>                 Michael.