• Jim Nelson's avatar
    Remove SQLHeavy: Closes #5034 · 0e2a5334
    Jim Nelson authored
    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.
    0e2a5334
version-001.sql 2.03 KB