The tests are expected to run with a maximum message size of 20000
used by both client *and* server - server must be configured
accordingly.
Then the Add and Update operations in the interrupted sync with
client B are done with an item that is larger than the message size
and thus depends on <MoreData> support. On resume, only the second
half is sent and the recipient must assemble the complete item.
Instead of comparing just the numeric status, compare the strings
first. That way the CPPUnit equality warning will contain a readable
explanation of the failure.
Comments on TransportFaultInjector and TransportResendInjector
clarify what these tests do.
CLIENT_TEST_INTERRUPT_AT can be set to -1 to run just the
uninterrupted part of each test.
When removing a child event (RECURRENCE-ID set), the behavior of EDS
for the parent event (without the RECURRENCE-ID) is
undefined. Client::Source::ical20::testLinkedItemsRemoveNormal assumed
that the parent's LAST-MODIFIED was not affected.
Nightly testing recently showed that at least some EDS versions modify
the parent when removing a child. More specifically, they add an
EXDATE to the parent for the recurrence that was removed. This is
reasonable. The puzzling part is that this test failure was not
observed earlier. This might be because the test could be timing
dependent: if creating the parent and removing the child fall into the
same second, then the parent is not considered as modified.
This patch modifies the test so that it passes both when the parent is
updated and when it isn't.
In addition, this failure points towards another problem: if a server
like ScheduleWorld deletes a child event on a client, it first sends
an update for the parent and then the removal request for the
child. We should not report the parent as modified during the next
sync. Again, depending on the timing, this may or may not have
happened.
This is based on the assumption that the server knows about
child/parent events and does the right thing. If the parent event was
not modified on the server when removing the child, then with this
patch we are not going to fix that in the next sync. Such servers
should be fixed.
This patch therefore adds a check to testLinkedItemsRemoveNormal for
the change tracking and fixes EvolutionCalendarSource::removeItem() so
that it updates the change tracking when necessary. Because
TrackingSyncSource is not prepared to deal with a removal that has
side effects, its tracking config node must be made accessible for
this to work.
When automatic backups are enabled (the default), SyncSourceRevisions
and derived classes like TrackingSyncSource called listAllItems()
twice, once during backup and once while checking for changes.
This patch introduces caching of the result returned by the first
call. During a normal session, that will be during backup, with
change detection reusing the information. If backups are off, the
call will happen during change detection, as before.
Sharing of the listAllItems() result with change tracking only
works for the backup that is created at the start of a sync.
This piece of information is passed to the backend as part of
the BackupInfo structure.
The advantages of this change are:
- more efficient, in particular for sources where listAllItems() is slow
- avoids a race condition (backup stores one set of items, changes
are made, change detection works with another set)
That race condition is both fairly theoretical (short time window) and
had no impact on the correctness of the sync, only on the output (data
comparison would not show all changes synced later).
Now the race condition still exists if changes are made while a sync
runs, which is the bigger problem that still needs to be solved (for EDS,
see MB #3479).
Restoring data also calls listAllItems(). It does not use the cached
information, just in case that it is to be called more than once per
instance, and because there is no benefit.
This is the API change which will allow a SyncSource implemenation
to reuse data and files from a previous backup. Right now, neither
the caller nor the callee actually use this option.
const char * type = (string (type) + "_noutc").c_str()
keeps a pointer to a temporary std::string instance. That
memory might be deallocted when the pointer is used later.
We could have used
type = "ical20_noutc";
but I preferred to adapt the "if" clauses instead. That way we
might also introduce a "itodo20_noutc" later on.
Phones may not fully support UTC time. As the case for Nokia 7210c, it can
understand the UTC time sent by server but will not convert it back to UTC time
when sending back to server.
Use 'CLIENT_TEST_NOUTC' to use this special test configuration.
Enabling only the super datastore to SyncContext.
Avoid changing the databaseid automatically for super source as it has special
meaning.
There are a later commit fixing the LocalTest problem for super datastore.
testManyItems now checks that the statistics are correct. This
is based on the assumption that all active sources use the same
number of test items.
The new testManyDeletes triggers a problem with 222 loop detection:
when the message to the server contains many deletes, the server
may require so many reply messages, that the client has to send
5 Alert 222 messages in a row and incorrectly treats this as a loop
that has to be aborted.
The intention is to get rid of the historic and inconsistent
naming of some classes and their corresponding files:
* EvolutionSyncClient = class derived from Funambol's SyncClient,
* SyncEvolutionConfig = SyncEvolution's config
With the strict 'namespace SyncEvo' and the syncevo/ path prefix for
most header files it is no longer necessary to have "SyncEvolution" or
"Evolution" in the names. This patch thus renames as follows:
EvolutionSyncClient => SyncContext
EvolutionSmartPtr => SmartPtr
SyncEvolutionCmdline => Cmdline
SyncEvolutionConfig => SyncConfig
SyncEvolutionUtil => util
The former EvolutionSyncClient always had a role that went beyond just
running a sync, for example it also provided config access. With the
upcoming server support it also won't be just a client. Thus the new
name "SyncContext".
The 'syncevo/' prefix is used throughout the code now.
removed whenever the prefix made it clear that the file belongs
to SyncEvolution. This helps finding incorrect include paths.
Quotes should be used exclusively for SyncEvolution files which don't
have a specific prefix yet (test.h, config.h) to help identifying
them.
Added syncevo/declarations.h, which has
This is now used for all SyncEvolution source files, except
for the GTK UI, which is written in plain C. In the library
it helps to avoid name clashes.
The reason for using defines instead of spelling out "namespace SyncEvo"
is twofold:
1. if that should ever become necessary, it is easier to
rename the namespace via configure options by changing
the define
2. editors don't indent the whole file content
Since Memotoo has issue in parsing '<', '>' and client-test.cpp
hard-code a case including this character, remove them to make
cases passed.
To continue check this, I add them into the imemo20.ics test files
to keep testing these 2 characters.
Also update memotoo's test memo patch.
The main motivation for this change is that it allows the implementor
of a backend to choose the implementations for the different aspects
of a datasource (change tracking, item import/export, logging, ...)
independently of each other. For example, change tracking via revision
strings can now be combined with exchanging data with the Synthesis
engine via a single string (the traditional method in SyncEvolution)
and with direct access to the Synthesis field list (now possible for
the first time).
The new backend API is based on the concept of providing
implementations for certain functionality via function objects instead
of implementing certain virtual methods. The advantage is that
implementors can define their own, custom interfaces and mix and match
implementations of the different groups of functionality.
Logging (see SyncSourceLogging in a later commit) can be done by
wrapping some arbitrary other item import/export function objects
(decorator design pattern).
The class hierarchy is now this:
- SyncSourceBase: interface for common utility code, all other
classes are derived from it and thus can use that code
- SyncSource: base class which implements SyncSourceBase and
hooks a datasource into the SyncEvolution core;
its "struct Operations" holds the function objects which
can be implemented in different ways
- TestingSyncSource: combines some of the following classes
into an interface that is expected by the client-test
program; backends only have to derive from (and implement this)
if they want to use the automated testing
- TrackingSyncSource: provides the same functionality as
before (change tracking via revision strings, item import/export
as string) in a single interface; the description of the pure
virtual methods are duplicated so that developers can go through
this class and find everything they need to know to implement
it
The following classes contain the code that was previously
found in the EvolutionSyncSource base class. Implementors
can derive from them and call the init() methods to inherit
and activate the functionality:
- SyncSourceSession: binds Synthesis session callbacks to
virtual methods beginSync(), endSync()
- SyncSourceChanges: implements Synthesis item tracking callbacks
with set of LUIDs that the user of the class has to fill
- SyncSourceDelete: binds Synthesis delete callback to
virtual method
- SyncSourceRaw: read and write items in the backends format,
used for testing and backup/restore
- SyncSourceSerialize: exchanges items with Synthesis engine
using a string representation of the data; this is how
EvolutionSyncSource has traditionally worked, so much of the
same virtual methods are now in this class
- SyncSourceRevisions: utility class which does change tracking
via some kind of "revision" string which changes each time
an item is modified; this code was previously in the
TrackingSyncSource
After a http request is sent out, while the client is waiting for response,
the server found client is unreacheable (client side network down temporarily or
intermidate router down), so the server stops sending and closed the tcp
conenction, causing a half closed connection at client side.
To fix this, client side will timeout (60 seconds) during wating and will
resend previous request to retry. After 3 failed retries, it will finally
give up leading to an abort. The timeout and retry count can be customized
in server config file.
Mobical.net always initiates a slow sync mode when it
has no any data for a typed information. Do not check
sync mode when setting this environment variable as
'1', 't' or 'T'.
The Synthesis Engine doesn't count these items because Synthesis wants
the engine to count only items deleted by the remote side. For our
statistics this looks a bit unrealistic (items before sync + added - deleted
does not add up to items after sync), so we now track items deleted
locally and use that number instead of the Synthesis statistics for deleted
items when we know that it is not complete.
In the command line, we show detailed statistics. In the GUI, it shows
up as part of the locally applied changes.
The new testComplexRefreshFromServerSemantic test covers this particular
aspect of the statistics.
This test checks whether the server a) creates no duplicates
during a slow sync (also covered by testManyItems) and b) correctly
associates the client's item with its own copy.
As described in Bugzilla #4703, the ScheduleWorld server currently
has a problem with the later (for contacts) and fails to delete
the item on the client, apparently because it doesn't remember the
LUID correctly. It also fails this test for text because it creates
duplicates.
ignore some properties that google server will get lost
not comparing PHOTO encoded data because google always return jpg format
Ignore value mismatch in FN, NOTE, ORG and TEL
Add google specific case to workaround a test failure because of delele failed
to clean the previous data (A know issue in server)
slightly change a test case to workaround google
google server can not delete cleanly; if a later test sends a contact with the
same N field, the server will trigger a client side update which is not
expected.
The only way that I found not to execute a test was not to register
it in CPPUnit. FilterTest() does this by replacing a valid test
or test group with a dummy one, SkipTest, which just prints the
test name and that it is skipped.
Registering tests has to be intercepted at multiple levels:
- CPPUNIT_TEST in test suites
- ADD_TEST in ClientTest
- addTest in ClientTest
Not currently intercepted are complete test suites (CPPUNIT_TEST_SUITE).
The main purpose of this patch is to avoid running the time consuming
suspend and interrupt tests, but this feature might also be useful for
other tests, which is why it was implemented in a more general way.
Without that information, the wrong files are compared, leading to false
test failures. Because getItems() is also called indirectly via import(),
this change ripples through several functions.
We were using the same set of test cases for different server, this
is a bit limited; now importItem will first check a server specific
test case file and will fallback to the general case file if failed.
The makefile is also changed.
Funambol server has a length limitation for 'DESCRIPTION' property. If item is larger
than the limitation, the rest part will be lost. Add the environment variable
"CLIENT_TEST_MAX_ITEMSIZE" to allow controlling this size
Both EvolutionSyncSource::backupData() (implemented for the memo source
in the TrackingSyncSource base class) and Client::Source::text::testImport
must dump items in the native format, the one which is used for restore
and for the test cases. See Bugzilla #3967 and #3929.
This broke during the 0.9 development cycle, but wasn't detected during
automated testing because the necessary tests weren't enabled for
the "text" source until recently.
Now createItem() is passed a hint what the desired format is. "raw"
is used for backup and testing.
Also removed obsolete exportData() call in EvolutionCalendarSource.
This was used before introducing the newer backupData() call.
Without that method most of the tests couldn't be done and combined
tests (Client::Sync::vcard30_ical20_itodo20_text::testCopy) failed
with an assertion.
All of the predefined tests share the same methods, so moved them
into the general section. Backends which need something else have
to override the defaults or unset them, if nothing works.
The test didn't actually cause a conflict as originally intended because at
one point client A instead of client B was synced.
The result of the conflict resolution wasn't checked thoroughly enough: only
the number of items on the client was checked to determine whether items
were duplicated. Now the test also compares the actual data on client A and B
to find out whether they are in sync.
With ScheduleWorld, it was found that in some cases (VEVENT with new and
different properties added by both clients), the client which
caused the conflict was not updated (Bugzilla #2036). Catching this
required some changes in the test data.
Just to be sure, a refresh-from-server requests the actual data on the
server. This will detect cases where the server modifies the data, but
then updates neither client A nor B.
Config::testcases_server had no useful purpose. The extra dump()
method became redundant because the EvolutionSyncSource API *always*
returns "native" items and thus the generic method works fine.
During a refresh-from-client sync, the server has to delete all items
that it currently has before adding those sent by the client. This
new test covers that. It complements the testRefreshSemantic test,
which did that for the other direction and thus was renamed to
testRefreshFromClientSemantic.
The server also needs to tell other clients to delete the items
that were deleted this way during a refresh-from-client. This is
not currently tested.
As with the previous change from AGPLv3 to LGPL v2.1, this is covered
by copyright ownership and/or the Funambol contributor agreement.
The motivation for adding v3 is greater flexibility regarding
reusing the code in other places and relicensing it.
Comparison was missing altogether. Items were not imported as text/calendar
because the type wasn't set. Creating new items didn't work because <<REVISION>>
was in the wrong place: it needs to be in the DESCRIPTION, so that SUMMARY and first
line of DESCRIPTION remain identical (expected by some peers and our own sync source).
