[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