views:

223

answers:

2

Hi,

This is my problem: I need to store a lot of log messages and thought it would be smart to keep it in a SQLite3 database to be able to search and filter it easily.

I will display the log messages in a standard list widget (using wxWidgets). The list will have several columns and can be sorted and filtered by the user.

Now, I'm not sure what is the best way to handle this. I'm thinking about some possible solutions:

  1. Read all messages to memory. When there is a new or changed log message (at a random position in the list) the whole list will have to be refreshed. Same thing when the user wants to filter the list or sort on a different column.
  2. Read all ID's into an array and retrieve the full log message on demand (when the user scrolls the list so that they are made visible).
  3. Use the SQL-interface to fetch the results on demand, using SQL to select the exact sub-result that is required.

But really, I'm just not used to working with this kind of problem, so any tips are appreciated!

+2  A: 

How about using pagination?

SELECT *
FROM logs
WHERE ...
ORDER BY ...
LIMIT offset, count

Where offset and count are values you can choose. You can use this to get any number of log entries. Then add a next button to allow the user to view the next page of entries. Combined with the ability to filter and a sort, the log search cannot be any easier.

Nadia Alramli
That's what I would have done on a webpage, but it does not seem so natural in a list. I think the user should be able to reach the entire data set with the scrollbar.
Jonatan
however, that got me to thinking: i could use different scrollposition as pages, so that i always keep say 1.000 entries in memory, and when the user scrolls beyond that i load a new set.
Jonatan
If you have a lot of log messages then displaying them in one window is not practical. I'm not sure how to implement that in wxWidgets. But you can load more log messages when the user scrolls down for example.
Nadia Alramli
ah, you beat me to it :)
Nadia Alramli
A: 

Started writing this as a comment to Nadia's answer, but I started rambling and it got too long :)

Keep in mind that as the number of log entries gets very large, the scroll bar becomes useless. The tiniest movement in the scroll ends up moving through the list drastically. That makes it impractical for a user to use to search the list.

Think about why users will actually be looking through these entries and design around that. Very large lists aren't just hard to work with in code, they're also hard for the users to work with. I would probably give them some filter criteria and paged results.

Tom H.
i will give them the possibility to filter, search and sort the result, but in worst case (the user choose to see all) i don't want the application to crash. I'm going with a linear paged-result-solution as above.
Jonatan