Is that possible to get hierarchy of branches?
I have to know the father of a given branch
I have to know the children of a given branch
How do I get it by cleartool?
I prefer not to be based on a view config-spec
Thank you!
With base ClearCase, you cannot know the parent of a branch, because it can vary from file to file: a file can start branch 'B2' from '/main/LATEST', another can start the same branch from '/main/B1/LATEST'.
For ClearCase UCM, you can determine the parent of a branch by querying the ancestors of a Stream (since the branch is name after the stream):
cleartool lsstream -anc myStream#pvob
That is possible because branches are linked to Streams, which are organized following a strict hierarchy a Parent Stream / Children Streams.
Note that describing a stream (cleartool describe, using fmt_ccase) only gives you access to the children streams: hence the lsstream -ancestor, in order to display its parent.
Related
With ClearCase, you create views with cleartool mkview, and delete them with cleartool rmview. Similarly, you create branch types with:
cleartool mkbrtype -c "some comment" my_brance_type
... but there is no cleartool rmbrtype which would be the opposite command. How do you remove a branch type in CMake?
The unintuitive command for removing a branch type is:
ct rmtype -rmall brtype:my_branch_type
See the detailed documentation about this on IBM's website.
Note: The -rmall is often (always?) necessary even if you don't have any objects with revisions of that branch type. (At least with ClearCase v8.0.0.x.)
Warning: a cleartool rmtype won't succeed if you have any instance of the type you want to remove.
Even with -rmall, it can still fail if the instance you remove (here a branch based on a brtype) has hyperlink and other UCM metadata which would be dangling if the branch disappear.
I have a JCR content repository implemented in ModeShape (4.0.0.Final). The structure of the repository is quite simple and looks like this:
/ (root)
Content/
Item 1
Item 2
Item 3
...
Tags/
Foo/
Bar/
.../
The content is initially created and stored under /Content as [nt:unstructured] nodes with [mix:shareable] mixin. When a content item is tagged, the tag node is first created under /Tags if it's not already there, and the content node is shared/cloned to the tag node using Workspace.clone(...) as described in the JCR 2.0 spec, section 14.1, Creation of Shared Nodes.
(I don't find this particularly elegant and I did just read this answer, about creating a tag based search system in JCR, so I realize this might not be the best/fastest/most scaleable solution. But I "inherited" this solution from developers before me, so I hope I don't have to rewrite it all...)
Anyway, the sharing itself seems to work (I can verify that the nodes are there using the ModeShape Content Explorer web app or programatically by session.getRootNode().getNode("Tags/Foo").getNodes()). But I am not able to find any shared nodes using a query!
My initial try (using JCR_SQL2 syntax) was:
SELECT * FROM [nt:unstructured] AS content
WHERE PATH(content) LIKE '/Tags/Foo/%' // ISDECENDANTNODE(content, '/Tags/Foo') gives same result
ORDER BY NAME(content)
The result set was to my surprise empty.
I also tried searching in [mix:shareable] like this:
SELECT * FROM [mix:shareable] AS content
WHERE PATH(content) LIKE '/Tags/Foo/%' // ISDECENDANTNODE(content, '/Tags/Foo') gives same result
ORDER BY NAME(content)
This also returned an empty result set.
I can see from the query:
SELECT * FROM [nt:unstructured] AS content
WHERE PATH(content) LIKE '/Content/%' // ISDECENDANTNODE(content, '/Content') works just as well
ORDER BY NAME(content)
...that the query otherwise works, and returns the expected result (all content). It just doesn't work when searching for the shared nodes.
How do I correctly search for shared nodes in JCR using ModeShape?
Update: I upgraded to 4.1.0.Final to see if that helped, but it had no effect on the described behaviour.
Cross-posted from the ModeShape forum:
Shared nodes are really just a single node that appears in multiple places within a workspace, so it's not exactly clear what it semantically means to get multiple query results for that one shareable node. Per Section 14.16 of the JSR-283 (JCR 2.0) specification implementations are free to include shareable nodes in query results at just one or at multiple/all of those locations.
ModeShape 2.x and 3.x always returned in query results only a single location of the shared nodes, as this was the behavior of the reference implementation and this was the feedback we got from users. When we were working on Modeshape 4.0, we tried to make it possible to return multiple results, but we ran into problems with the TCK and uncertainty about what this new expected behavior would be. Therefore, we backed off our goals and implemented query to return only one of the shared locations, as we did with 2.x and 3.x.
I may be wrong, but I'm not exactly sure if any JCR implementation returns multiple rows for a single shared node, but I may be wrong.
I am using the fantastic extension by Yiiext "nested-set-behavior":
https://github.com/yiiext/nested-set-behavior
I am interested to know if anyone can let me know how to move (up or down) a root node when I am running the nested set with multiple roots.
tree example:
Phones (root node)
1.1 Mobile
1.2 Fixed
Cars (root node)
2.1 Fast
2.2 Slow
2.3 Average
Planes (root node)
3.1 Large
3.2 Small
At the moment when I pull out the full tree and show this to the user I get the above result.
I would like to be able to move "Cars" before "Phones".
Is there any way of doing this?
I have tried:
$cars = Category::model()->findByPk($cars_id);
$phones = $cars->prev()->find();
$cars->moveBefore($phones);
This gives me an error in the moveAfter method of the nested set behavior class.
Any one done this before?
Thanks
Dave
As the doc suggest the the prev() method returns :
Array of Active Record objects corresponding to ....
Therefore you have to approach this with different way e.g
$phones = Category::model()->findByPk($phones_id);
$cars = Category::model()->findByPk($cars_id);
$cars->moveBefore($phones);
Or other approach which suits your application scenario
Your code could be fixed by :
$cars = Category::model()->findByPk($cars_id);
$phones = $cars->prev()->find();
foreach($phones as $phone){
$cars->moveBefore($phone);
}
which does not make sense ;)
(p.s: did not test this code)
As I understand, you have 3 nodes, which are the roots.
The problem is that the methods moveAfter() and moveBefore() can not be applied to the main roots. You are trying to move a node, relatively another node, but they are in different trees.
If cars and phones have a common root, it will be success.
In other words, you operate with nodes in different trees, which know nothing about each other.
is it possible to make Lucene query in alfresco that finds nodes based on their parent/children properties? For example i want to find all the nodes that have the property "foo" set to '1' and have nodes associated to them by a child association with the property "baz" set to '2' (maybe specifing somehow the name of their child association)
something like
#crl\:numeroAtto:"6555" AND #crl\:firmatario:"Marco rossi"
Where "numeroAtto" is a property of the parent node and "firmatario" is a property of the child. The association type is "firmatari" (It's not in the query because i don't know how to use it)
To be even clearer i'm trying to tell lucene: "Find all nodes that have the property numeroAtto set to 6555 and that have children (association type with the children: firmatari) with the property "firmatario" set to Marco rossi.
Thanx in advance
You can't search on associations, so what we do is not to build slow queries.
But add a new d:text property of the association on the parent Type.
So it's searchable through Lucune.
To make it fully working, create a Java Behaviour which checks on content update. And when 'your' association is found it adds it to the d:text property.
This way lucene searches are very quick.
There is no direct lucene way to do this.
Another idea: the first would return all of the parent nodes and then build searches based on the root of each returned node.
what is a proper way of organizing files in a wcm that is using JCR. Let's say the total file count is 100,000+ files and total file size is about 50-70GB.
Is it better to organize files by fie types ( and create sub directories to further group the files by some category)
What are the advantages. Does it make any difference while using query api, maintenance, or something.
Proposal 1:
--shared
------images
------pdf
------movies
--location1
------images
------pdf
------movies
--location2
------images
------pdf
------movies
Proposal 2:
--pdf
-------shared
-------location1
-------location2
--images
--------shared
--------location1
--------location2
.. etc
Take a look at this: David's Model: A guide for content modeling
Some highlights:
Data First, Structure Later. Maybe.
Drive the content hierarchy, don't let it happen.
Workspaces are for clone(), merge() and update().
Beware of Same Name Siblings.
References considered harmful.
Files are Files are Files.
ID's are evil.
Whatever you do, make sure you don't end up with more than a 1000 child nodes under any given node.
Just as in any (real) file system, when you want to list a folder with a lot of files/subfolders in it, it can take some time.
By default Jackrabbit 2.x will now hash up the user space.
ie:
/users/s/sa/sandra
/users/s/si/simong
...
I would personally go for your first proposal as it makes more sense.
We have a webapp where all our users can upload/delete/modify their files in JCR and did it this way:
/_users/s/si/simon/public
/_users/s/si/simon/public/My Pictures
/_users/s/si/simon/public/My Pictures/2010/06/Trip to the US
/_users/s/si/simon/public/My Pictures/2010/06/Trip to the US/DC1001.jpg
/_users/s/si/simon/private/account_details.txt
...
We're loosely following the way home folders are done in UNIX-like systems.
We try to hash up all the things we (reasonably) can. Like the for example the user space (/s/si/simong) but also things like messages:
/_users/s/si/simong/messages/2009/12/25/ab34ed87dee
/_users/s/si/simong/messages/2010/03/12/e4f1de3cd48
...
However it's up to the individual user to not have more then 1000 child files in a given folder (we do warn them though.)
Doing it this way also gives you a nice benefit of exercising Access Control.
ie: everthing under ~/private is only read- and writeable by the current user, ~/public is readable by everybody.