search

HughP / simal

Automatically exported from code.google.com/p/simal
0 stars 0 forks source link

Database can't be reused across Simal instances #304

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
The way the simalID has been set up prevents the reuse of the database.

simalIDs are of the form <instance ID> + "-" + <entity ID> (as implemented in 
AbstractSimalRepository.getUniqueSimalID(String)).

The <entity ID> is used by the REST API, eg. for querying a '/person' or a 
'/project'.

The full simalID is used for storing projects, persons and categories. This 
means that when a entity ID is converted to a full simalID, the instance ID 
must be the same as the one by which the entity has been stored. 

This makes it impossible to reuse the database with a different instance. It is 
also not possible to backup a database and restore it to another instance.

Original issue reported on code.google.com by sander.v...@oucs.ox.ac.uk on 23 Jun 2010 at 10:11

GoogleCodeExporter commented 9 years ago 
Before changing this you need to review the issues that led to this design 
choice, e.g.

Issue 190

I have no problem with this being revisited, as long as the resean for this 
design decision is fully understood. In other words, I'm not saying the design 
is good, just that there is logiv in the madness.

Original comment by ross.gardler on 23 Jun 2010 at 10:19

GoogleCodeExporter commented 9 years ago

Original comment by sander.v...@oucs.ox.ac.uk on 8 Jul 2010 at 11:21

GoogleCodeExporter commented 9 years ago 
I'm tempted to move this to milestone 0.6 ad priority Low (or even mark it as 
won't fix) as it only affects reuse of the data across instances as this is not 
intended to be the case. 

Each instance is intended to keep its own data. If instance foo wants to know 
about project bar then it is supposed to seek out as much data as it can and 
collect it. Foo would first ask all other known instances of Simal what they 
know and then would, optionally seek new sources.

It is not intended to move data from one instance to another.

Original comment by ross.gardler on 20 Jul 2010 at 2:33

GoogleCodeExporter commented 9 years ago 
I created this issue because the following use cases are currently not possible 
without nasty tweaks:

- Restore a database
- Migrate a database to a newer Simal version

The ultimate effect being that we need to recreate the whole database from 
external sources when we migrate a running Simal instance. This heavily effects 
using Simal in practice because all changes that are made through the UI, eg. 
adding people, reviews or assigning categories, are lost when we migrate to a 
new Simal version.

I think the best solution to this is to make the Simal ID consistent across 
migrations. 

So to make sure it's clear: this issue is NOT aimed at making two running 
instances of Simal share data.

Original comment by sander.v...@oucs.ox.ac.uk on 20 Jul 2010 at 2:55

GoogleCodeExporter commented 9 years ago 
OK, I agree the restoring a database is a critical use case.

I did do some work some time ago on a data backup mechanism, but I don't think 
there is a restore yet. See Issue 157 and Issue 260

Original comment by ross.gardler on 21 Jul 2010 at 11:01

GoogleCodeExporter commented 9 years ago 
The code that writes the backup is:

        FileWriter writer = new FileWriter(backupFile);
        getRepository().writeBackup(writer);
        writer.close();
        logger.info("Backup file written to " + backupFile.getAbsolutePath());

Original comment by ross.gardler on 21 Jul 2010 at 11:04

GoogleCodeExporter commented 9 years ago 
Note there is a script for backup that works nicely as a workaround for the 
backup/restore issue.See 
http://code.google.com/p/simal/source/browse/trunk/uk.ac.osswatch.simal.web/src/
main/python/backupAllProjects.py

Moving to 0.6 and dropping priority

Original comment by ross.gardler on 14 Mar 2011 at 2:08

GoogleCodeExporter commented 9 years ago 
Issue 410 has been merged into this issue.

Original comment by ross.gardler on 14 Mar 2011 at 2:11