nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

As we transition to the new Hyland Community, some post links may be temporarily disrupted as we finalize redirects. We apologize for the inconvenience and are working to resolve this as quickly as possible. Details.

Changes to the content model have unpredictable results

pitt1

We're in the process of developing our content model and make frequent changes to it. Our practice is modify the model.xml file on the server and restart Alfresco, then load some content into Alfresco under the new model, by adding our newly defined aspects to the content. We will then decide that the model is not quite right and add/modify/delete properties and aspects. Before actually making these changes effective by restarting the Alfresco server, our practice has been to delete all documents/folders that contain aspects from our custom model so that we don't have documents lying around with bad aspects.

Recently, we made a dramatic change involving: creating a new model, and leaving an existing one in place (the 'old' one). We then took the namespace out of the old model and put it into the new model, giving it a new namespace prefix. The old model was then given a new namespace, but kept the same prefix. In summary, we had:

Before:
oldModel.xml
prefix: old
namespace: http://oldmodel.com/old

After:

oldModel.xml
prefix: old
namespace: http://newoldmodel/newold

newModel.xml
prefix: new
namespace: http://oldmodel.com/old

Most aspects previously in old were moved to new. We now restart our server without event (i.e. no indication of a problem). When we try to add content and apply aspects that are now defined in new, the server gives a warning that these aspects don't exist. By fluke, my colleague removed the old model (by changing the name of old-model-context.xml), and the aspects defined in new can now be added. We're puzzled as to why. We want to have both models in place…

Find more posts tagged with

Comments

davidc

I would suggest providing a new namespace URI to new or updated models only. Changing the namespace URI of an existing model is not good practice, unless you're re-starting from a completely clean slate (including repository).

One approach is to add a version number to your URI e.g.

http://model.com/v0.1
http://model.com/v0.2

Whenever you create a new model.

Assigning a new prefix to your new model is not an issue.

pitt1

To clarify…does this mean that if I have a namespace http://mymodel.com/1.0 and want to make incremental changes, and call the new namespace http://mymodel.com/1.1 to reflect that I have made a change, I need to leave the original model in place as is, and in addition add the new model, even though my goal is to make a replacement? If I have both 1.0 and 1.1 models in place, do each of them need to have a separate namespace prefix, or can they be the same? My understanding is that in alfresco, namespace prefixes as well as the namespaces themselves need to be globally unique.

So if I've already changed the namespace in an existing model on a repository with existing content, is there an alternative way of remedying this situation besides blowing away and re-loading my repository? Luckily this is a development system, but I'd rather not have to do this as we're working on arriving at a model. I also don't think that once we reach the production stage, we'll be immune to the necessity of making changes to the model. So on a production system, which changes to a model are acceptable and won't cause unpredictable/unstable results? Is there documentation regarding how model changes affect the system?

Thanks,
Julie

davidc

The only safe model changes are additions. Please note, at this time, Alfresco does not perform any validation (or data changes) when an updated model is deployed.

So, whilst in development, if your model is changing beyond additions, i.e. removing stuff, renaming stuff, then you need to very careful, unless you start a new development repository to accomodate the updated model, or you create a new model (i.e. allocate a new namespace uri). When creating a new model, existing test data is not accessible with that model. It's only accessible with the old model. That may be ok for testing purposes.

In production, you have to ensure you make compatible changes (i.e. additions) otherwise you need to migrate your existing data. Alfresco, at this time, does not do this for you. This is no different from any other data public data format, such as XML schema or SQL schema.

pitt1

Thanks David, that does help. Last followup question: while in development and making deletions/renaming changes to the model, how do I wipe clean my repository without re-installing Alfresco? My best guess would be to remove all files from repository.root and delete my database schema (perhaps by dropping and re-creating the schema). Does this sound about right?

csiege

I have battled the problems that can occur in changing content models after content is associated to them. We have learned to just be very
careful and try to only consider adding to a model.

This is what I use to reset my dev environment quickly to start over…

I am pretty sure these where/are in some alfresco build/release somewhere…

db_remove.bat

@echo off
rem —————————————
rem MySQL remove DB command
rem —————————————

echo Deleting Alfresco database and user…
mysql -u root -p < db_remove.sql

echo Deleting indexes…
del /s /q alf_data‍‍‍‍‍‍‍‍‍‍

db_setup.bat

@echo off
rem —————————————
rem MySQL create DB command
rem —————————————

echo Creating Alfresco database and user…
mysql -u root -p < db_setup.sql

echo Database prepared.
‍‍‍‍‍‍‍‍‍‍

I place them where I can run them quickly and thats it. 🙂

Chris

pitt1

We're using Oracle, so the commands are different, but I get the idea! Don't you also need to delete everything in your repository.root directory to make sure there's no clash there with an empty database?

Do you guys plan on implementing some sort of warnings/errors when things are removed from the content model. Now that I know we shouldn't be removing stuff, I can learn to avoid it, however we're humans and make mistakes, so it would be nice to get some kind of message at startup… If this is something you guys might do but haven't considered yet, I can put it into Jira…

csiege

The line…

del /s /q alf_data‍

removes all the files.

I don't work for alfresco… just a paying user, so I would enter a jira ticket for that. 🙂 I don't plan on adding that myself. 🙂

sergi_l

Hi all!

In the development phase where we are is a valid option. We can remove all the database and create it again.
But it's not a valid option in another environment if some day some property changes. We would have to remove just the old documents or convert them. How does it work?

Manually I can delete the old documents from Alfresco UI before deploying the new model. But if some documents keep stored there, after deploying the new model, these files won't be read/edited/deleted no more, they'll remain as rubbish.
If this happens, how can I remove this corrupted documents? Will they be deleted through a script? Database query?

Please, help! Thanks.
Regards,

Sergi