https://bugs.freedesktop.org/show_bug.cgi?id=88695

Lionel Elie Mamane <[email protected]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Whiteboard|                            |EasyHack
                   |                            |DifficultyInteresting
                   |                            |SkillCpp SkillSql

--- Comment #1 from Lionel Elie Mamane <[email protected]> ---
The cache window is m_pMatrix in in dbaccess::ORowSetCache (file
dbaccess/source/core/api/ORowSetCache.[ch]xx). The idea would be to have
something like a collection windows, accessible through their respective
ranges, instead of a single window.

Range is just two integers, the first row of it and the first row that is not
inside (so that the range is from inclusive to exclusive, like m_nStartPos and
m_nEndPos are now). They replace m_nStartPos and m_nEndPos which should be
removed.

To choose the data structure that will hold the range-to-window mapping, the
basic requirements are:
1) Given a position (row number),
   to have easy/fast lookup of the window that position is in.
2) Easy/fast insertion of a new window, merge of two windows,
   split of a window in two and resizing and moving of windows.

The general solution would be something like a balanced lookup tree. Since we
don't intend to have many windows, a simple array of (range, window) pairs
could be adequate.

The idea is to keep a single m_nPosition/m_bAfterLast/etc, since that's the
current design.

As a second step, we could separate all of those into "one per attached
RowSet(Clone)", which would avoid the need for the RowSet(Clone)s to constantly
reposition their cache for fear that another RowSet(Clone) has moved it. On
second thought, this might be the only way to go since else the cache wouldn't
know when to kill an unused window, since it wouldn't know when it is unused!

(In reply to Lionel Elie Mamane from comment #0)
> 2) They each have their own cache, but the caches cooperate. Complex.

Since apparently clones cannot make any insert/updates, these things would be
less difficult than I thought. You can investigate that and do that instead of
you wish. Essentially, I have in mind a design that the cache of the RowSet
knows of the caches of the RowSetClones and thus invalidates/updates/... them
on modification/insertion/deletion.

-- 
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Libreoffice-bugs mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

Reply via email to