Limitations and differences

This page gives an overview of technical limitations of the migration process and differences between the source and target instance.

Due to technical reasons, and especially due to different implementation details between the easydb5 API and the fylr API, a restored instance is not a 100% true copy of the source instance. There will be more differences between easydb5 and fylr instances, but also between restored fylr instances.

The differences mentioned on this page are not exhaustive!

Other differences between source and target instances might occur.

General differences

IDs can not always be restored. In general, sequential IDs are assigned to inserted basetypes and records by the target fylr instance. This is necessary to avoid possible collisions between imported IDs and IDs which have been assigned during the purge process, or are already in the system during partial migrations.

A few exceptions are made, but these are limited to a few IDs and a few record types. For all other relations between records and basetypes, lookups to unique references are used. Existing references are restored, but missing references are generated during the migration process. This means that any restored basetype will have a reference, either the original reference, or a new reference:

Basetype	Restored IDs	Fallback for missing reference
User	-	user:<source ID>
Group	-	group:<source ID>
Pool	-	pool:<source ID>
Tag Group	-	taggroup:<source ID>
Tag	Tag ID	tag:<source ID>
Collection	-	collection:<source ID>
Message	-	message:<source ID>

For records, the System ID (_system_object_id) and the UUID (_uuid) are restored. The Global Object ID (_global_object_id) is partially restored, the old instance ID is replaced by the new instance ID, but the System ID part is not changed: <System ID>@<Source Instance ID> will become <System ID>@<Target Instance ID>. The Object ID (_id) is not restored, but lookups referencing the System ID are used.

Since IDs are generally not restored, scripts which use hard coded IDs are not recommended!

Lookups should be used instead. References are unique, and all restored objects will either have a reference or a System ID.

Differences between easydb5 and fylr

In addition to IDs, there are more differences between easydb5 and fylr. Since there are different technologies and concepts behind the systems, some data can not be restored at all, and will be ignored or changed.

Migration of Events

If events are migrated (see parameter --include-events), there are differences between easydb5 and fylr. For some events, the eventtype or the basetype is changed. Also there are events in easydb5 which have no matching event in fylr, these events are not migrated at all.

The event info block will be migrated without any changes. IDs which relate to objects, files, etc., are replaced during the restore process. This is done for IDs on top level (object_id), and known IDs in the info block.

In the following table, all migrated events are listed, including changes which are automatially done during the restore process. Events which are not listed here are never migrated from easydb5 to fylr.

Eventtype in easydb5	Eventtype in fylr	Notes
ASSET_DOWNLOAD_CONFIRMATION_MESSAGE	ASSET_DOWNLOAD_CONFIRMATION_MESSAGE	Basetype is set to message, there was no basetype in easydb5 The following IDs in the info block are replaced: assets.#.id: The ID is replaced with the new file ID
CUSTOM_TYPE_UPDATER_RESPONSE	CUSTOM_DATA_TYPE_UPDATER	Eventtype is changed
CUSTOM_TYPE_UPDATER_START	CUSTOM_DATA_TYPE_UPDATER	Eventtype is changed
CUSTOM_TYPE_UPDATER_RESPONSE_ERROR	CUSTOM_DATA_TYPE_UPDATER_ERROR	Eventtype is changed
CUSTOM_TYPE_UPDATER_RESPONSE_FAILED	CUSTOM_DATA_TYPE_UPDATER_ERROR	Eventtype is changed
SCHEMA_COMMIT	DATAMODEL_COMMIT	Eventtype is changed
DETAIL_VIEW	DETAIL_VIEW
EMAIL_SENT	EMAIL_SENT
DOWNLOAD_EXPORT	EXPORT_DOWNLOAD	Eventtype is changed
ASSET_DOWNLOAD	FILE_DOWNLOAD	Eventtype is changed Basetype is changed from asset to file The following IDs in the info block are replaced: export._id: The related record is not migrated, the ID is set to null export_user_id: The ID is replaced with the new user ID
ASSET_EXPORT_DOWNLOAD	FILE_DOWNLOAD	Eventtype is changed Basetype is changed from asset to file The following IDs in the info block are replaced: export._id: The related record is not migrated, the ID is set to null export_user_id: The ID is replaced with the new user ID
OBJECT_DELETE	OBJECT_DELETE
OBJECT_INSERT	OBJECT_INSERT
OBJECT_UPDATE	OBJECT_UPDATE
SEARCH	SEARCH
USER_CREATED	USER_INSERT	Eventtype is changed Basetype is set to user, there was no basetype in easydb5
USER_LOGIN	USER_LOGIN	Basetype is set to user, there was no basetype in easydb5
USER_LOGOUT	USER_LOGOUT	Basetype is set to user, there was no basetype in easydb5
WEBHOOK_OK	WEBHOOK	Eventtype is changed
WEBHOOK_ERROR	WEBHOOK_ERROR