[fpc-pascal] Master Detail relationship in SQLdb

[Michael Van Canneyt]

On Sat, 14 Jul 2007, Martin Schreiber wrote:

> On Saturday 14 July 2007 12.55, Michael Van Canneyt wrote:
> >
> > > I spent about 150-200 hours to find, report and fix bugs in the FPC DB
> > > area BTW. :-)
> >
> > Which I appreciate: There are indeed 15 bugs in Mantis about this.
> > (spending on average 10-13 hours per bug is a lot)
> >
> Yes it was a hard time. :-)
> The worst (a spurious SIGSEGV in TBufDataset) I hunted a whole week. Because 
> MSEgui must work with the latest stable FPC version I had to find workarounds 
> for every bug, a very time consuming process.
> If I count right, I posted 114 FPC reports up to now, some of them in the pre 
> Mantis era.

45 in Mantis, to be exact. 15 of which are database bugs.

> Contrary to Borland where I reported many bugs too and none of 
> them  was fixed at the time I abandoned Delphi/Kylix, the FPC team fixed most 
> of the bugs in reasonable time. The fastest fix was in 15 minutes!

We do our best :)

As for 'reasonable time': this always depends on the needs of the user (you)
and the available time/estimated seriousness of the FPC maintainers: it
is perfectly normal that there is a difference between the appreciation of
the 2 involved parties :-)

To a soldier, his own death or well-being is a serious matter, but the general 
needs to consider all soldiers :-)
 
> > But it doesn't explain why you decided to fork the code, when I see
> > no good reason for this:
> > - The user base for each set of components gets smaller.
> > - People don't know what to use.
> > - The maintainers are divided over too much code.
> 
> The main reason is time. I found out that I need less development time if I 
> write most of the library my self from scratch instead to use existing base 
> components for my "exotic" needs.
> Another big problem is the fast release cycle of MSEide+MSEgui compared with 
> FPC. I need to copy up to date FCL files into the MSEgui distribution anyway 
> to build a working system, so the step to do a fork is small.
> The smaller user base is no problem for me, I don't need to sell MSEide+MSEgui 
> and the user base of FPC-FCL is so much bigger than the user base of MSEgui 
> that the move of users from FCL to MSEgui should be no problem for FPC.

Yes and no. MSEGui users are FPC users, obviously, but we would of course
appreciate it if the benefits of some of your work are available to more people.

As for the time cycle: Like I said:

After 2.2, we plan to start using the package system.
At that time, the release cycles of the compiler & rtl are independent of
the release cycles of the packages and FCL. That should solve your release
problem: I have no problem with discussing with you the needs of the FCL
release cycles.
 
> > So, once more, I propose to 'merge' whatever you need so we can develop
> > a decent set of components, suitable for all.
> >
> The most questionable component in FCL-DB is TBufDataset <-> tmsebufdataset.
> I fear the needs of FCL and MSEgui are too different to let a merge be 
> possible. Some needs of MSEgui are out-of-scope of the ordinary FPC user and 
> the FPC developers (fast widestrings on all platforms comes into mind).

I am aware of the widestrings difficulty. However, I am sure this can be solved.

I discussed this with Joost, and we decided that the issue of WideStrings
in TBufDataset and descendents can be solved very easily with 1 extra property,
which would make it transparant for MSEGui users and other users. No need to
change any existing code.
 
> What is the result of your discussion with Bram and Joost of the matter to 
> merge FCL-DB and MSEgui ?

Well, 4 things were identified. As you correctly state, the biggest issue
is TBufDataset and it's partner tmsebufdataset:

- The widestring issue. We do not see this as a problem, as it can be solved 
  very easily.

- The structure of the memory buffer is another matter. You do not store the
  string fields in the buffer itself, rather the pointer is stored in the buffer.
  Joost tried something similar once, but dropped the issue, but in principle
  he likes the idea. I looked at the matter now,  and I am not convinced that 
  this is the optimal solution. According to me, this way of doing will use a 
  lot more memory and will be slower due to additional memory manager calls. 
  So we decided that Joost will do some benchmarking before we make any proposals.

- Blobs are handled differently, but a lot has changed in sqldb since you forked
  the code. We don't think this will be a problem.

- The use of RECNO as the bookmark for the cursor. 
  This issue can be handled on the index level.

In the process, I noticed you have a sqlite3conn descendent of TSQLConnection,
so I changed the sqlite3 unit so it can be loaded dynamically, and then I made
a copy of the sqlite3connection component and completely reworked it so it is 
independent of msegui, and so it conforms more to the coding style of the rest 
of the FCL, and which has also been tested by Joost. It's in subversion; Obviously, 
your name is duly referenced as the original implementor.

All in all, I'm fairly confident that we can merge most if not all of the code 
to everyone's satisfaction.

Does all this sound reasonable to you ?

Michael.