[fpc-devel] Warning for sqldb and fpc 2.1.1 users

Luiz Americo Pereira Camara pascalive at bol.com.br
Mon Apr 3 00:35:24 CEST 2006


Bram Kuijvenhoven escreveu:
> Micha Nelissen wrote:
>> On Sat, 01 Apr 2006 18:33:10 -0300
>> Luiz Americo Pereira Camara <pascalive at bol.com.br> wrote:
>>
>>>>> And what about recno? Just define it as -1, or do a quick count to 
>>>>> get
>>>>> the current record number?
>>>>>     
>>> Take a look at TCustomSqliteDataset implementation. In its 
>>> implementation a count is done each time.
>>>> Store the recno with/in the linked list entry ?
>>>>
>>>>   
>>> It has two drawbacks: increase memory usage and when inserting, 
>>> deleting all following records must be updated.
>>
>> An array of records has the same problem, no ? So these are not 
>> drawbacks
>> IMHO.
>
> I think, when using an array, the RecNo is implicit from the position 
> in the array.
>
>
> Implementing the RecordCount property is not so much a problem (using 
> increments/decrements on changes), but updating RecNo's can be 
> troublesome I think.
>
> I can imagine it is possible to store some kind of relative RecNo's 
> with only a sparse subset of the record in a smart way, allowing O(log 
> N) times for inserting/deleting records and O(log N) time for getting 
> RecNo's. I do not know whether this is indeed possible, and the 
> implementation would not be easy I think.
>
> Another option is to update the RecNo's only when requested, i.e.:
> - each record stores a record number
> - when inserting/deleting, all RecNo's from that record on are marked 
> as 'dirty' (this needs only storage of a LowestDirtyRecNoIndex)
> - when requesting the RecNo of an item with 'dirty' stored RecNo, one 
> could recalculate the RecNo's of record LowestDirtyRecNoIndex until 
> the record whose RecNo is requested at that time
>
> To prevent the memory overhead of storing RecNo's, it is even possible 
> to only allocate the RecNo storage space only when some RecNo is 
> retrieved for the first time. This allows people to save memory by 
> never using RecNo, but still use RecNo if they really need.
>
> Of course, using Bookmarks is a very good substitute for RecNo's! And 
> if one wants to enumerate the records, one can still do so by keeping 
> a private counter while traversing the dataset with calls to Next. (In 
> one of my applications I even have an array of Bookmarks -- I think I 
> overlooked the RecNo property, which would take away the necessity of 
> using such an array, if I'm understanding things correctly).
This is what you get in TSqliteDataset: while RecNo is something 
expensive (both to get and to set the RecNo it walks through the linked 
list), BookMarks are almost inexpensive (both in memory requirements and 
to set/retrive) because the bookmark is really the list item pointer 
(Take a look at the implementation). Every time you choose a design 
(any) you have strengths :-)      and weakness :-( . It's a matter of 
what you want, what's the priority.

Luiz



More information about the fpc-devel mailing list