2012-04-23 18:54:26 -07:00
|
|
|
set(SQL_DEST share/geary/sql)
|
|
|
|
|
|
Remove SQLHeavy: Closes #5034
It is done.
Initial implementation of the new database subsystem
These pieces represent the foundation for ticket #5034
Expanded transactions, added VersionedDatabase
Further expansions of the async code.
Moved async pool logic into Database, where it realistically
belongs.
Further improvements. Introduced geary-db-test.
Added SQL create and update files for Geary.Db
version-001 to version-003 are exact copies of the SQLHeavy scripts
to ensure no slight changes when migrating. version-004 upgrades
the database to remove the ImapFolderPropertiesTable and
ImapMessagePropertiesTable, now that the database code is pure
IMAP.
When we support other messaging systems (such as POP3), those
subsystems will need to code their own database layers OR rely on
the IMAP schema and simply ignore the IMAP-specific fields.
ImapDB.Account fleshed out
ImapDB.Folder is commented out, however. Need to port next.
ImapDB.Folder fleshed out
MessageTable, MessageLocationTable, and AttachementTable are now
handled inside ImapDB.Folder.
chmod -x imap-db-database.vala
OutboxEmailIdentifier/Properties -> SmtpOutboxEmailIdentifier/Properties
Moved SmtpOutboxFolderRoot into its own source file
SmtpOutboxFolder ported to new database code
Move Engine implementations to ImapDB.
Integration and cleanup of new database code with main source
This commit performs the final integration steps to move Geary
completely over to the new database model. This also cleans out
the old SQLHeavy-based code and fixes a handful of small bugs that
were detected during basic test runs.
Moved Outbox to ImapDB
As the Outbox is tied to the database that ImapDB runs, move the
Outbox code into that folder.
Outbox fixes and better parameter checking
Bumped Database thread pool count and made them exclusive
My reasoning is that there may be a need for a lot of threads at
once (when a big batch of commands comes in, especially at
startup). If performance looks ok, we might consider relaxing
this later.
2012-06-14 14:47:53 -07:00
|
|
|
install(FILES version-001.sql DESTINATION ${SQL_DEST})
|
|
|
|
|
install(FILES version-002.sql DESTINATION ${SQL_DEST})
|
|
|
|
|
install(FILES version-003.sql DESTINATION ${SQL_DEST})
|
|
|
|
|
install(FILES version-004.sql DESTINATION ${SQL_DEST})
|
2012-08-25 18:45:25 -07:00
|
|
|
install(FILES version-005.sql DESTINATION ${SQL_DEST})
|
2013-02-25 15:01:37 -08:00
|
|
|
install(FILES version-006.sql DESTINATION ${SQL_DEST})
|
2013-02-25 20:18:37 -08:00
|
|
|
install(FILES version-007.sql DESTINATION ${SQL_DEST})
|
2013-03-11 14:34:33 -07:00
|
|
|
install(FILES version-008.sql DESTINATION ${SQL_DEST})
|
2013-05-14 18:07:53 -07:00
|
|
|
install(FILES version-009.sql DESTINATION ${SQL_DEST})
|
2013-06-21 18:20:56 -07:00
|
|
|
install(FILES version-010.sql DESTINATION ${SQL_DEST})
|
2013-06-25 16:49:59 -07:00
|
|
|
install(FILES version-011.sql DESTINATION ${SQL_DEST})
|
|
|
|
|
install(FILES version-012.sql DESTINATION ${SQL_DEST})
|
2013-07-19 16:28:56 -07:00
|
|
|
install(FILES version-013.sql DESTINATION ${SQL_DEST})
|
2013-09-25 16:16:22 -07:00
|
|
|
install(FILES version-014.sql DESTINATION ${SQL_DEST})
|
2013-09-25 18:04:58 -07:00
|
|
|
install(FILES version-015.sql DESTINATION ${SQL_DEST})
|
2013-10-02 12:56:25 -07:00
|
|
|
install(FILES version-016.sql DESTINATION ${SQL_DEST})
|
2014-01-30 10:36:15 -08:00
|
|
|
install(FILES version-017.sql DESTINATION ${SQL_DEST})
|
2014-02-14 16:06:10 -08:00
|
|
|
install(FILES version-018.sql DESTINATION ${SQL_DEST})
|
2014-02-21 15:00:57 -08:00
|
|
|
install(FILES version-019.sql DESTINATION ${SQL_DEST})
|
Fix a number of database hiccups
1) Use docid instead of id in search table.
We had previously included an 'id INTEGER PRIMARY KEY' column in the
MessageSearchTable, assuming it would get the same rowid alias treatment
as it does in non-FTS tables. That assumption was wrong: it was being
created as a FTS column. This fixes it so we use docid everywhere.
To fix the old incorrect docid values, we simply blow away the search
table and let the natural search table population process, which now has
the correct docid insertion code, fix the problem.
This also removes the id column from the search table creation SQL, but
this will only affect new users. Upgraders will see an empty, vestigal
id column in their search table. Since SQLite doesn't easily let you
remove columns, it's just easier to ignore the column than go through
all the work to fix it.
2) Do as many rowid lookups as possible in batches, instead of doing
them individually in loops. This speeds up working with large sets of
email.
3) Rejigger indices on the MessageLocationTable to make certain queries
faster. This creates a new covering index in particular for the email
prefetcher, which previously had to sort using a temp table. The new
index should work in the general case too, as we should never be looking
at ordering without folder_id (and since folder_id comes first, it works
as an index on just folder_id, too).
4) For bonus measure, log all slow queries (> 1s execution time) to
debug output.
Closes: bgo #725929
2014-03-12 16:39:22 -07:00
|
|
|
install(FILES version-020.sql DESTINATION ${SQL_DEST})
|
|
|
|
|
install(FILES version-021.sql DESTINATION ${SQL_DEST})
|
2014-08-13 12:20:05 -07:00
|
|
|
install(FILES version-022.sql DESTINATION ${SQL_DEST})
|
2014-12-16 12:21:09 -08:00
|
|
|
install(FILES version-023.sql DESTINATION ${SQL_DEST})
|
2014-12-18 17:00:47 -08:00
|
|
|
install(FILES version-024.sql DESTINATION ${SQL_DEST})
|