Relatively simple question:
If I have already created items to an existing schema and that changes for an upgrade how do I automate data migration?
That is, if my content model changes between revision 1.10 of my product and 1.11, how do I migrate the data while avoiding the "model is not compatiable" type of errors? For the purposes of this question, the alfresco version can be assumed to not have changed. However, resetting the Solr index and needing to re-index can be assumed to be needed!
thanks#
Make sure to execute the steps in the proper order. It is your responsibility and Alfresco does not offer much support here. For the sake of an example, let's assume you are removing a mandatory property. I would do something like this:
Upgrade the model and make the property optional
Remove the value from all content instances
Upgrade the model with the property removed
This example should work without an index rebuild. Other changes, such as when you change how a property is indexed require an index update. If in doubt, rebuild the index.
Related
When trying to update a Custom Content Model in Alfresco I decided to upload and activate a new copy and delete the old one. I found out this doesn't work.
So my question is what will happen now and how can I fix this?
What will happen where the two content models are the same?
What will happen where the two content models define the same aspect, but differently?
Does one take precedent over the other?
Would editing the 2 in the properties to be identical get around the problem?
Starting from scratch with this repository is an undesirable option at this time. I'm looking for the simplest solution possible.
It's not simple as that. If you already have some documents or folder associated with a model, you can't delete it without breaking your datas.
Also, Alfresco doesn't support multiple declarations of a model or type or aspect. If it's the case it doesn't start.
The only way you have to upload a new version of your model is by uploading a version containing ONLY added properties, types or aspects. If your new model's version contains modificated or deleted properties, types or aspects, you will have to migrate each node programaticaly.
i am trying to extend alfresco's document management by running a script. So far, i have managed to create a Custom Model with a Custom Type and Property as seen below:
the said Custom Type is under this Custom Model (never mind the Custom Aspect for now)
the custom type is working so far, i managed to apply it to a certain document as you can see below (Notice the Control Code Field)
now what i want to do is to add an auto incrementing function that will be set as the value of the Control Code Property (ie: [FILE0012])
i tried utilizing the scripts rule from alfresco but it seems like the commands are limited to that of alfresco's functionalities. not even alert() or console.log functions work. i thought that if i can make a script that could call an ajax to my php server, i can extract the document's property, and insert it to my database and get the rowid then attach it to a word "FILE" so it becomes the Control Code Property (ie: a document was inserted to my database at row 1996, then the Control code is [FILE1996], this is because i joined '[FILE' and 1996 and ']'
but like i said, what happened was, the javascript commands are limited to that of alfresco's needs.
i tried to make my research but i've only bumped on 2 outdated (and i mean outdated) threads dating back to 2006-2010. which does not help me quite well with Alfresco's current build structure.
i hope someone can help me with here. connecting to the database is not mandatory, but if i can make it do as such then it'll give me quite a rather amazing results.
Take a look at the "cm:countable" aspect. You do not have uniqueness guaranteed OOTB, so take that into account.
Example:
http://www.avantec.se/howto-create-an-auto-increment-field-on-an-object-in-alfresco/
When I publish Visual Studio database project targeting SQL Server 2012 it generates script containing drop views and functions statements and then creating these views and functions, although there are no changes in these views and functions in DB project at all comparing to database. How can I disable this behavior?
I would like to have publish output equal to what I get when I generate script after schema compare (project to database), so only affect objects for which there are changes.
Are you absolutely sure that there are no differences? Even a difference in the "NOT FOR REPLICATION" options can cause issues. Do a compare of the live database against your project and see what is different (Tools - SQL - Compare Schema). If there are differences, fix them. Otherwise, you shouldn't be seeing anything to actually change. As Keith noted, check to make sure you don't have the "always re-create" option enabled. That could be giving you trouble, though it doesn't usually drop individual items, but the entire database. You may also want to check collations - if those are different you could have issues.
Make sure the "Always re-create database" option is unchecked in the Advanced publish settings.
Finding the reason for why SSDT thought the scheme was different I think is the first point of call. SQL Scheme compare is your friend here. (In VS under Tools => SQL => New Scheme Comparison...)
Computed column definitions and constraint definitions were definitely candidates, as was potentially column ordering. Ironically I did have one issue with a computed column but it was not the definition, it was the fact that I didn't add NOT NULL to the end of the column definition (which is the default of course) but SSDT saw that as different everytime.
We have a CRM 2011 managed solution that includes some changes to a standard entity (account) - i.e. new form and some extra fields. In most cases, we can install without a problem as the changes are merged. However we have encountered some instances where a client has renamed the Account entity to something else (Company) as an unmanaged chage (including view names) and our solution changes the entity name and view changes back to 'Account' when installed, based on the 'last one wins' rule.
My question is, is it possible to protect un-managed changes, so that we do not overwrite un-merged changes? i.e. similar to Managed Properties?
Any suggestions would be most appreciated.
Unfortunately, I don't think this is possible although maybe I don't fully understand what you are aiming to do. When you export a solution it will save a snapshot of all the included components. When you reimport, it should set all of the included components as they were when you exported them. If you exported the account entity with a customized name, what sort of logic would you want in place to disallow that change to be imported?
If anyone else has a solution to this, I'd be glad to see it but I haven't come across one yet.
I have a custom implementation of a multi tenant code first system basically SQL Schema Divisions of the tenants. I am using the ToTable method to map the schema correctly on the first call, but as I have read about the model being cached changing the schema on the second call do a different tenant does not work. Is there any ways in EF 4.1 to disable the caching or to rebuild the model every time.. Yes i know this is not great for performance. Thanks for any help..
Although it is an old question, but for all those who face this issue and end up finding this question for a possible solution. Here it goes...
Initially caching could be turned off by setting the "CacheForContextType" property of the ModelBuilder to ‘false’ in the OnModelCreating method. This method is defined in DBContext as virtual and needs to be overridden. But in EF 4.1 this property has been removed, since model creation is an expensive process and the Microsoft team wanted to promote a better pattern. Check this link
It seems like the Build() command on the ModelBuilder is what you're looking for.
modelBuilder.Build().Compile().CreateObjectContext...