Merge lp://qastaging/~kevin-wright-1/u1db-qt/synchronizer-18-juni-i into lp://qastaging/u1db-qt

Proposed by Cris Dywan
Status: Merged
Merged at revision: 100
Proposed branch: lp://qastaging/~kevin-wright-1/u1db-qt/synchronizer-18-juni-i
Merge into: lp://qastaging/u1db-qt
Diff against target: 2269 lines (+1981/-7) (has conflicts)
13 files modified
CMakeLists.txt (+2/-2)
examples/u1db-qt-example-6/u1db-qt-example-6.qdoc (+387/-0)
examples/u1db-qt-example-6/u1db-qt-example-6.qml (+227/-0)
modules/U1db/CMakeLists.txt (+4/-0)
modules/U1db/plugin.cpp (+2/-0)
src/CMakeLists.txt (+5/-1)
src/database.cpp (+319/-2)
src/database.h (+20/-1)
src/index.cpp (+13/-1)
src/query.cpp (+9/-0)
src/query.h (+2/-0)
src/synchronizer.cpp (+879/-0)
src/synchronizer.h (+112/-0)
Text conflict in src/database.cpp
Text conflict in src/index.cpp
To merge this branch: bzr merge lp://qastaging/~kevin-wright-1/u1db-qt/synchronizer-18-juni-i
Reviewer Review Type Date Requested Status
U1DB Qt developers Pending
Review via email: mp+170623@code.qastaging.launchpad.net
To post a comment you must log in.
Revision history for this message
Cris Dywan (kalikiana) wrote :

syncLocalToLocal should use U1db::Database to re-use the initialization, which would also give it the existing sanity checks

the logic of onSyncChanged is probably best moved into a separate callback. Changing resolve_to_source and targets would trigger it as well. Thus it becomes possible to delay/ thread the real sync and avoid any delay at startup.

Even with keeping in mind it's incomplete //uncommented code and conflicts make reviewing a little hard.

I love the description of the sync via HTTP/ JSON, this would be nice to get into one qdoc-ified comment and make it accessible as documentation.

100. By Kevin Wright

Migrated listTransactionsSince function from Syncrhonizer class to Database class. Previously this class used the path of a database file rather than an instance of an active Database class' database connection. With the function now hosted by the Database class itself the path of the file and opening of the database connection within the scope of the function is no longer required (i.e. the class' active database connection is used instead).

101. By Kevin Wright

Migrated getSyncLogInfoFromLocalDb function from Synchronizer class to Database class, and renamed getSyncLogInfo. Previously this class used the path of a database file rather than an instance of an active Database class' database connection. With the function now hosted by the Database class itself the path of the file and opening of the database connection within the scope of the function is no longer required (i.e. the class' active database connection is used instead). This function is used by the Synchronizer class' getLastSyncInformation function to retrieve data from the source and target databases. The data represents information that one database has about the other the last time they synced (if ever).

102. By Kevin Wright

Fixed a regression relating to the active source Database for Synchronizer. In the function syncLocalToLocal is the ability to overide the main source database (the 'source' property) with another database when a query is defined within an individual 'target' definition (with the key 'source_query').

103. By Kevin Wright

Added the initial steps for sync with a remote database. There are several steps in the archtitecure for remote sync, whereby the server and client communicate information between each other (e.g. previous sync transations, new data). This commit consists of the first step, where the client initiates the sync transaction and the server responds with known information about previous syncs if any. Also in this commit is the first roughed in code for the second stage of a sync transaction, where the client (aka source) begins sharing information about new data since the previous sync between the two databases (if any previous transaction occured).

104. By Kevin Wright

This commit continues the work to support the second stage of a local to remote sync transaction, where the client (aka source) begins sharing information about new data since the previous sync between the two databases (if any previous transaction occured). The code now is up to the point of initiating the post to the remote server, but at this time is showing bad request errors. The post is not sending complete data at this time, which may be the reason for the bad request error.

105. By Kevin Wright

This commit continues the work to support the second stage of a local to remote sync transaction, where the client (aka source) begins sharing information about new data since the previous sync between the two databases (if any previous transaction occured). The post is sending complete data as of this commit, but the server is still replying with a bad request error. On the surface everything appears to comply with the high level architecture documentation, but something is obviously still incorrect.

Preview Diff

[H/L] Next/Prev Comment, [J/K] Next/Prev File, [N/P] Next/Prev Hunk
The diff is not available at this time. You can reload the page or download it.

Subscribers

People subscribed via source and target branches

to all changes: