2015-04-04
| ||
14:02 | {1196} introducing RecordVersionSynchronizeMasterStart and RecordVersionSynchronizeSlaveStart/Stop methods for easy master/slave replication of a table for [3453f314d9] - also renamed RESTful synchronization method as RecordVersionSynchronizeSlave, and updated documentation check-in: a33c699430 user: ab tags: trunk | |
2015-04-03
| ||
15:20 | {1188} added CurrentFrame() method recognition so that TServiceRecordVersionCallback would be able to process "jumbo frames" incoming modifications within a BATCH, for faster Master/Slave replication over WebSockets [3453f314d9] check-in: 50d534f628 user: ab tags: trunk | |
09:48 | {1187} tested and fixed Master/Slave replication using TRecordVersion field over WebSockets [3453f314d9] check-in: 310bb783b3 user: ab tags: trunk | |
2015-04-02
| ||
19:26 | {1186} introducing TServiceRecordVersionCallback class to implement TSQLRestServer.RecordVersionSynchronizeCallback() callbacks, and new regression tests for [3453f314d9], including fixes check-in: 6a4166cd6e user: ab tags: trunk | |
08:05 | {1185} fixes and refactoring of TSQLRestServer.RecordVersionSynchronizeCallback() implementation - see [3453f314d9] check-in: 4462a6f626 user: ab tags: trunk | |
2015-04-01
| ||
21:09 | {1184} introducing TSQLRestServer.RecordVersionSynchronizeCallback() method, able to register a callback interface which would be called each time a write operation is performed on a given TSQLRecord with a TRecordVersion field - see [3453f314d9] check-in: e78b7e3e24 user: ab tags: trunk | |
2015-03-31
| ||
20:59 | {1168} allow RecordVersionSynchronize*() to work even if both source and destination TSQLModel do not match - see [3453f314d9] check-in: 8190a332aa user: ab tags: trunk | |
18:34 | {1167} several fixes, including support for TRecordVersion up to 58 bits for [3453f314d9] (they were silently truncated to a much lower value by the compiler) check-in: e1d969fcf1 user: ab tags: trunk | |
18:07 | {1166} added TSQLRestServer.RecordVersionSynchronizeToBatch() method which allows to retrieve a list of updates as a TSQLRestBatch, starting from a supplied TRecordVersion - see [3453f314d9] check-in: ccd5ddb087 user: ab tags: trunk | |
15:29 | {1164} introducing TSQLRestServer.RecordVersionSynchronize() method using a TRecordVersion field to maintain a modification versioning information on any table - implement one-way synchronization for feature request [3453f314d9] check-in: ced6e37637 user: ab tags: trunk | |
06:51 | {1158} several fixes for TRecordVersion type support - see [3453f314d9] check-in: 02de4e41d6 user: ab tags: trunk | |
2015-03-30
| ||
18:39 | {1157} introducing new TRecordVersion type for TSQLRecord published properties, allowing easy synchronization of row values, using a monotonic version number - first part of [3453f314d9] check-in: d0664ef5bf user: ab tags: trunk | |
2015-01-16
| ||
09:24 | • Ticket [3453f314d9] Auto-Synch: between mORMot servers (as cache or for branch office cache), and potentially mORMot clients (offline mode) status still Open with 3 other changes artifact: a0be31c72e user: ab | |
2015-01-08
| ||
08:17 | • Ticket [3453f314d9]: 3 changes artifact: e151a7c410 user: ab | |
08:16 | • New ticket [cac2e379f0] Asynch ORM Writes. artifact: 6380738697 user: ab | |
2014-12-31
| ||
10:32 | • Ticket [cde2d68eb6] Automatic sharding for BigData storage status still Open with 5 other changes artifact: 427b2ea0f5 user: ab | |
10:32 | • Ticket [aa230e5299] Implements one-way callbacks from the server status still Open with 5 other changes artifact: ef1b83848c user: ab | |
10:32 | • New ticket [17958b22c0] Monitoring feature. artifact: 8a0fb77cc9 user: ab | |
10:14 | • Ticket [01da096f72] TSQLRecordMappedAutoID and TSQLRecordMappedForcedID classes status still Open with 4 other changes artifact: 364fdef097 user: ab | |
09:49 | • Ticket [3453f314d9] Auto-Synch: between mORMot servers (as cache or for branch office cache), and potentially mORMot clients (offline mode) status still Open with 3 other changes artifact: a6f7b8fb47 user: ab | |
09:35 | • New ticket [cde2d68eb6] Automatic sharding for BigData storage. artifact: 509cea8bf0 user: ab | |
2014-11-14
| ||
14:08 | • Ticket [3453f314d9] Auto-Synch: between mORMot servers (as cache or for branch office cache), and potentially mORMot clients (offline mode) status still Open with 3 other changes artifact: 4d87495c69 user: ab | |
2014-08-23
| ||
07:44 | • Ticket [3453f314d9]: 5 changes artifact: b4a8783a7c user: root | |
2014-08-19
| ||
09:41 | enhanded documentation, mainly about TSQLRestStorageRemote class, TSQLRestServer.RemoteDataCreate() method and TSQLRestServerRemoteDB class for feature request [3453f314d97d] check-in: d9e53fd620 user: User tags: trunk | |
2014-08-18
| ||
13:33 | added TSQLRestStorageRemote class and TSQLRestServer.RemoteDataCreate() method and fixed TSQLRestServerRemoteDB class for feature request [3453f314d97d] - only direct ORM methods are available yet: still missing a TSQLVirtualTableRemote class check-in: 796e966c81 user: User tags: trunk | |
2014-08-17
| ||
12:22 |
some refactoring for feature request [3453f314d]
| |
2014-08-15
| ||
08:26 | • New ticket [3453f314d9] Auto-Synch: between mORMot servers (as cache or for branch office cache), and potentially mORMot clients (offline mode). artifact: 8c180da50b user: ab | |
Ticket Hash: | 3453f314d97dd80cebfd13cc50661bc483fdb2c8 | |||
Title: | Auto-Synch: between mORMot servers (as cache or for branch office cache), and potentially mORMot clients (offline mode) | |||
Status: | Open | Type: | Feature_Request | |
Severity: | Critical | Priority: | Immediate | |
Subsystem: | mORMot | Resolution: | Open | |
Last Modified: | 2015-01-16 09:24:46 | |||
Version Found In: | 1.18 | |||
User Comments: | ||||
ab added on 2014-08-15 08:26:42:
Following this forum thread discussion, we would like to introduce some kind of "Auto-Synch" beetween mORMot nodes. Idea is to let some tables be defined to be synchronized. We may imagine several use cases:
Server-side synchronization could be implemented via some dedicated interface-based services, published via a HTTP server. Some questions:
One of my concerns is that we need to setup a good unit test pattern before implementing all this as an "official" mORMot feature. root added on 2014-08-23 07:44:31:
We have added a After a call to Only direct ORM methods are available yet: still missing a You may also consider the Thanks to ab added on 2014-11-14 14:08:08: See also the discussion in this forum thread. A lot of input there, especially from real feedback when implementing similar design. We introduced the new ab added on 2014-12-31 09:49:02: In fact, this synchronization feature, when applied on a void database, would implement an ORM-level replication. We should take care that this process, which may be very resource intensive, would run in chunks, so that it would not block and only slightly slow down the main ORM process. This replication feature may be used also for proper re-balancing of data sharding, as requested by [cde2d68eb60463]. ab added on 2015-01-08 08:17:38: See also [cac2e379f02e] about "Asynch ORM Writes": this other feature request may be linked to this one. ab added on 2015-01-16 09:24:46: See also [292d00675ec] as local storage should be added for (SynCrossPlatform) clients. |