I'm using Apache Jackrabbit to store versioned data. I'm following the template listed on the Jackrabbit wiki for versioning basics, but there's one thing that isn't working as expected.
After I run the code from the wiki, I try saving another version of the node, then getting its version string:
child = parentNode.getNode("childNode");
child.checkout();
child.setProperty("anyProperty", "Blah3");
session.save();
Version thisVersion = child.checkin();
System.out.println(thisVersion.getName());
The output of this code is 1.0.0 , when I want it to be 1.1 . My goal is to be able to remove the last -- and only the last -- version of a node, and have the next version have the same name as the removed version. I only care about doing this when the node is being added; if I can check in the node, and read the name (to get the version number) without an exception being thrown, I'm fine with not being able to remove the version. Looking around the internet, I can't find a way to accomplish this.
You can't control the version naming, this is handled by the JCR implementation (in this case Jackrabbit). If you want to have your custom names for versions, use version labels.
Related
I am working on a nodejs project with typescript 2.2 that is using node 6.3.1 and I want to migrate from using typings to using #types. By doing so I ran into a set of questions related to whether there is a relationship between the version of the #types file and the corresponding npm package.
If I use jasmine as an example, the existing versions of the types definitions are
npm show #types/jasmine#* version
#types/jasmine#1.3.0 '1.3.0'
#types/jasmine#1.3.1 '1.3.1'
#types/jasmine#1.3.2 '1.3.2'
#types/jasmine#2.2.29 '2.2.29'
#types/jasmine#2.2.30 '2.2.30'
#types/jasmine#2.2.31 '2.2.31'
#types/jasmine#2.2.32 '2.2.32'
#types/jasmine#2.2.33 '2.2.33'
#types/jasmine#2.2.34 '2.2.34'
#types/jasmine#2.5.35 '2.5.35'
#types/jasmine#2.5.36 '2.5.36'
#types/jasmine#2.5.37 '2.5.37'
#types/jasmine#2.5.38 '2.5.38'
#types/jasmine#2.5.39 '2.5.39'
#types/jasmine#2.5.40 '2.5.40'
#types/jasmine#2.5.41 '2.5.41'
#types/jasmine#2.5.42 '2.5.42'
#types/jasmine#2.5.43 '2.5.43'
#types/jasmine#2.5.44 '2.5.44'
#types/jasmine#2.5.45 '2.5.45'
#types/jasmine#2.5.46 '2.5.46'
But if I examine the versions of the jasmine packages I have;
npm show jasmine#* version
jasmine#2.0.1 '2.0.1'
jasmine#2.1.0 '2.1.0'
jasmine#2.1.1 '2.1.1'
jasmine#2.2.0 '2.2.0'
jasmine#2.2.1 '2.2.1'
jasmine#2.3.0 '2.3.0'
jasmine#2.3.1 '2.3.1'
jasmine#2.3.2 '2.3.2'
jasmine#2.4.0 '2.4.0'
jasmine#2.4.1 '2.4.1'
jasmine#2.5.0 '2.5.0'
jasmine#2.5.1 '2.5.1'
jasmine#2.5.2 '2.5.2'
jasmine#2.5.3 '2.5.3'
Let’s say I am using version 2.4.0 of jasmine, which version of #types/jasmine should I pick? Because even if I use the latest of both, 2.5.46 does not match with 2.5.3.
Another example would be node itself, there are basically 6.0 or 7.0 versions in #types, and typings has only the ones shown below, being 6.0 reported as obsolete. So, what version of node are those typings actually tied to?
typings view dt~node --versions
TAG VERSION DESCRIPTION COMPILER LOCATION
UPDATED
7.0.0+20170322231424 7.0.0 github:DefinitelyTyped/DefinitelyTyped/node/index.d.ts#a4a912a0cd1849fa7df0e5d909c8625fba04e49d 2017-03-22T23:14:24.000Z
6.0.0+20161121110008 6.0.0 github:DefinitelyTyped/DefinitelyTyped/node/node.d.ts#fb7fbd28b477f5e239467e69397ed020d92817e7 2016-11-21T11:00:08.000Z
Thanks
The major and minor versions of the DefinitelyTyped packages are supposed to correspond to the major and minor versions of the package they are types for. The patch version increments whenever the .d.ts file changes for other reasons. Because the minor version shouldn't represent breaking changes, in theory, you can use the highest 2.x.y definition file available for a 2.a.b.c library.
But now the caveats begin.
The header in the definition file may not have changed at the right time
Library authors do not necessarily follow semver*
The definition file may not be 100% correct at any given point, in either direction (i.e. listing a 2.6 feature under a 2.5 version, or failing to list a 2.4 in function in the 2.5 file)
* In fact, no one does
A detailed explanation can be found in official docs FAQ: How do Definitely Typed package versions relate to versions of the corresponding library?
Busy migrating a report generation from Rails(Web) to a jruby command-line script.
Using:
jruby-1.7.11
ActiveRecord & ActiveSupport: 3.0.6
jdbc-sqlite3: sqlitejdbc-3.7.9.jar (with custom sqlite3.8 shared library)
jruby-poi: 0.9
Problem:
ResultTable.find_by_sql returns an array containing single length array's in stead of string's. ['country_NLD'] in stead of 'country_NLD'
Under Rails this seams to be working OK.
Questions:
How do I convert a single element array to a NON array even when its deep down in an other array?
I know that Postgress active record-jdbc-adapter has a setting called '...array.raw'. Is there some setting for SQLite3 available?
Thanks!
you did miss an important piece to mention: ActiveRecord-JDBC-Adapter's (gem) version ...
if you happen to be on 1.2.x I do recommend an upgrade to 1.3.x which shall have this incompatibility fixed, otherwise you should report the issue.
I'm having fun with a change to a content type field (from a node reference to a text field) which results in an error when a recreated feature is merged. The error is
FieldException: Cannot change an existing field's type. in field_update_field() (line 234 of /var/www/htdocs/modulesfieldfield.crud.inc)
At the moment, this is only affecting a merge back into a developer's workspace and the staging environment is a clean build from GIT, so unaffected. But it raises an early flag in terms of defining an update process when it goes to production.
When in production, I assume that it will be a matter of managing an export of each instance of that content type, remove the content type, install the recreated feature, migrate the exported data into the refactored content type and then apply any tests that may be defined for that change.
What is the recommended best practice process, i.e. the standard to follow to get it right at the outset?
Many thanks in advance
Best way is to tag your feature with a version.
First version: your old field and it's data
Second version: your old field definition and the new one.
In this version you can migrate the data contained in the old field within a hook_update_N().
Third version: simply remove old field definition
I hope to have answered your question as you expected
we have created a component in UCM. Many files were changed since but few files were not at all changed after version 1.
We can find the list of files using createdsince. but in this case we need to specify the date. Is there any way to find the list of files which are modified since creation.
In other words find list of files which has version greater than 1 in version tree.
You need to compare current versions with the stream/1 versions, and that isn't always the initial baseline of a component.
Actually, if you didn't imported an initial non-UCM label as a baseline, then the initial baseline is empty (no version in it).
The trick is, when using the query language, you cannot use version selector and a query
So, what you can do is apply a label to all version 1, and then look for all elements which have at least one version without that label (see find examples).
cleartool find . –version 'version(.../streamName/1)' –exec "cleartool mklabel V1 \"%CLEARCASE_XPN%\""
cleartool find . -version '{!lbtype(REL1)}'
I'm relatively new to Jackrabbit. In our application we never turned on SearchIndex section within repository.xml (so as workspace.xml) files because we always go directly to a given document using the JCR UUID reference. We are using Jackrabbit v2.2.1 and Oracle as the repository. Now our requirements are getting expanded as we would like to use the document metadata feature to store contextual info about a document so that we can use the metadata to retrieve a selected set of documents.
As the first step, I added the default SearchIndex section in workspace.xml file and restarted the JCR.
I saw a bunch of lines like this in my log file - then I saw it created the index folder under workspace area.
2011-07-05 15:04:01.724 INFO [WebContainer : 0] MultiIndex.java:1204 indexing... /vfs:metaData/21ee130e-978e-415f-bfd1-7aa03d91608c/vfs:attributes (3500)
I have the folder structure like this. When I create a document in JCR, I specify the metadata info as part of the document which is by a complex XSD type with tags like docType, uploadedBy, contextValue, etc.
/ (root)
/MyApp (sub-folder)
/documents/ (sub-folder)
/document-1.pdf (file)
/document-2.pdf (file)
/accounts/ (sub-folder)
/account.txt (file)
etc...
The following XPath expression works.
//jcr:root/vfs:metaData//*[vfs:attributes/vfs:docType='TAX_DOCS']
If I give wrong value, for example instead of 'TAX_DOCS', 'TAX', it returns no documents as expected which is great. This proves that the metadata is correctly stored as expected and it is used in the filter process correctly.
The problem with this query is that it starts searching from the root folder but I want to search from /MyApp/documents sub-folder only. So I tried this:
//jcr:root/MyApp/documents//vfs:metaData//*[vfs:attributes/vfs:docType='TAX_DOCS']
It returns nothing. Then I tried this too but no success.
//jcr:root/MyApp/documents//*[vfs:metaData/vfs:attributes/vfs:docType='TAX_DOCS']
So what am I doing wrong? Is anything in workspace.xml configuration that we need to set or missing?
Any help is appreciated.
Thanks, Jack
Drop the double slashed from anything but the last path component and use the # notation for the attribute value, resulting in:
/jcr:root/MyApp/documents//*[vfs:attributes/#vfs:docType='TAX_DOCS']
The // construct looks for the whole subtree instead of just the immediate children like / does. The JCR specification only requires implementations to support the // construct as the last step of the XPath query.