As I understand it in FileNet each version of a document gets its own ID. And if you create a new version then usually the properties are inherited from the previous version. So each version of a document has its own values for the properties.
Now I would like to add a property which is valid for all versions of a document (all versions != document class) for the use in a plugin. But I couldn't find any support for this. The only ugly concept I could come up with is the following:
Add a new property
Add all information to the lowest version of the document and retrieve it from there (otherwise you would need to modify all versions on changes)
Add a subscription which empties the property when creating the 2nd version (0.2, 1.0 or 1.1 usually) of the document and prevents deletion of the oldest version
Is there a more intelligent way?
You do not need a special Version series property - Version series IS that property.
Most of the time you only care about the current version of the document which can be accessed through any version of the document or its Version series. If that is not the case then you will have to iterate through all the versions of the document which are, again, most conveniently accessed through the Version series.
Since any document at any point of time is associated with its VS, when you need a relation to the VS you must use VS object reference or its ID.
Related
In sidekick, I can create as many versions of a page and can restore as well.
What I am looking for is, how to limit the number of "creation of page versions" . Suppose, after 5 versions I want to display an error - "more versions are not allowed".
I followed the link for reference but no luck: http://www.wemblog.com/2012/08/how-to-work-with-version-in-cq.html
You have to create a osgi:Config within repository for this (com.day.cq.wcm.core.impl.VersionManagerImpl).
You can control number of version created by activation by setting versionmanager.maxNumberVersions property.
Thanks in advance
There is no pro-active way to stop any versions from being created in the AEM repository. The configuration you are referring to is from: https://docs.adobe.com/docs/en/aem/6-2/deploy/configuring/version-purging.html#Version Manager
versionmanager.maxNumberVersions (int, default 5)
on purge, any version older than the n-th newest version will be removed. If this value is less than 1, purging is not performed based on the number of versions
This is the setting for version purge task which retains a maximum of n number of versions after purging where n is the number defined in the above config.
A preemptive version disabler won't work as versions are created from background tasks like workflows asynchronously. These tasks will fail without any feedback to user which will be problematic in most scenarios.
If you want to change the sidekick and disallow version creation, then you will have to rewrite core logic of the UI which can be a big task. Version Purging is the recommended way to setup your instance to limit the number of versions.
I am using a relay/graphql/googlecloud setup for a project that saves data immutably.
I have a set of fields that create a new record each time a modification is made to any of the fields structured like so:
Project
- Start Date
- End Date
- Description
- ...
- ...
The first time a project is created it is saved with a timestamp and a version number. For example:
1470065550-1
Any modifications after this creates a new version number but still uses the same timestamp.
1470065550-2
Bearing in mind that it is immutable there will potentially be a lot of versions of one project. If there are also a lot of projects this could result in a large number of records being fetched
If I want to fetch a list of projects from the datastore returning only the latest version of each one what would be the best way of going about this? As the version number increments i never know which one is the latest.
For example if I had rows containing 2 projects, both with multiple versions and I want to fetch the latest version of each:
1470065550-1
1470065550-2
1470065550-3
1470065550-4
1470065550-5
1470065550-6
1470065550-7 <--- Current Version for 1470065550
1567789887-1
1567789887-2
1567789887-3 <--- Current Version for 1567789887
Based on the rows above I need the query to just return the latest version of the two projects:
1470065550-7 <--- Current Version for 1470065550
1567789887-3 <--- Current Version for 1567789887
You probably want to change your tag to [google-cloud-datastore] instead of [google-cloud-storage] because you're probably missing people who are truly experts on datastore.
But just to offer my two cents on your question: It may be easiest to add a field for "current" and then use a transaction to switch it atomically. Then it is an easy filter for use in any other query.
If you can't do that, it's a bit tricky to answer your question because you haven't given us the query you are building to get this set of results. The typical way of getting a max value is to sort and set a limit of 1 like so:
var query = datastore
.createQuery('Projects')
.order('timestamp')
.limit(1);
But given the way you are storing the data, I don't think you can do this when you run over from -9 to -10 because -10 usually comes before -9 in lexicographical sorts (I didn't check how this works in datastore, however). You might need to zero pad.
I want to modify a form definition and upgrade all old filled form data also. But when I try to add new field, I found old input form data can not show the new field. it means I can not fill a new value in such old form data. Basically it means Orbeon does not support upgrade old form data to new definition.
Specific steps to understand such problem:
Create a form with two filed: Name and Id. save such form and
publish as version 1.
Fill such form and save it.
Open the form definition and add a new field, such as Address. Save it and Publish it. When ask publish as new one or overwritten, choose overwritten the version 1.
Open the filled form data you can see there is no new Address field show up.
Maybe it's not the right way to handle upgrade old data to new definition. I think we understand my requirement anyway.
The recommended way to handle this is to use versioning: when you publish an incompatible version of a form definition, you publish it under a new form definition version. For example:
create and publish form definition with version 1
create form data with version 1
create and publish incompatible form definition with version 2
existing form data is read with the form definition version 1
new data created with form definition version 2 is read with form definition version 2
There is currently no support for upgrading existing data from one version to the other (say version 1 to version 2). We do have an RFE for a minimal version of that.
See also this blog post for more.
We want to implement semantic versioning in our process, we are in version 1.0.0, and we have added two new functions. We will deliver these functions soon.
The question is: should we name our next version 1.1 or should we name it 1.2 because we have created two new functions.
In general, if we add n new functions, should we increment by n the minor component of the version, or we only increment by one in each delivery?
Version does not depend on how many functions
you have written in that particular release.
If your current version is 1.0.0 ,then
it should be 1.0.1 or 1.1 depend upon your
naming rule that you have put for your
product and dependencies.
There is no absolut right solution to version numbers.
The way most people i know do it is by increasing it on every version they plan on making available.
Microsoft themselves for example use the "major, minor, build, and revision" semantic for their version numbers. Just don't change up the way you do your version numbers after deciding on one. Because then they become useless :-)
I am creating a patch for a product. I don't want the patch to access the details of original files during patch installation. So in Patch creation property i have changed the value of IncludeWholeFilesOnly to 1.
But, 'IncludeWholeFilesOnly' property with a value of 1 (one) in the Patch Creation Properties (PCP) file delivers the wrong time stamp for the un-versioned dll's delivered in that particular patch.
problem is instead of dll modification time-stamp it shows the patch creation time stamp.
whereas if i change the value of IncludeWholeFilesOnly to 0 then everything will be proper.
How to fix this issue. Is there any other properties which i can modify so that time remains same.
Timestamps are irrelevant (even though they are to you) because they are not used anywhere to decide whether a file is the latest or not. So the system doesn't preserve them. When you install a non-versioned file it will set the create date and modify dates to be identical so that any modification will change the modify date, and Windows will assume that the file has been updated and so a patch won't overwrite it.
Versioned binaries are replaced or not depending on the version rules; data files are replaced or not depending on file hashes:
http://msdn.microsoft.com/en-us/library/aa368599(v=vs.85).aspx
and for example your non-versioned files:
http://msdn.microsoft.com/en-us/library/aa370531(v=vs.85).aspx
So this is the way it works, and dates aren't used to decide which is the latest. The best way to manage binary file versions is to use file versions.
Is there an actual problem, or do you just not like the way the dates change?