Hello,

As mentioned in some other comments, as soon as you want recursive queries, it becomes pretty complex. The DB is usually not the easiest way to get information in this case, as it’s often easier through Share or a Search query. But then if you want details on versions, that means you probably cannot use Search queries. I still think it would be easier to use the JavaScript Console in Share to get the details that you are looking for (maybe first a query to find all Nodes in the folder, and then parsing these with the JavaScript Console to extract the version details needed).

In you want to use a SQL query non-the-less, then it would be something that mixes both queries from the section “All documents from a custom type with version history” as well as “Recursively find the number of childs”. First in the recursive, you would get Node ID and then in the second time, you would retrieve all versions for all Node IDs from the list and display that as the outcome.

Also, please note that you need to take care of the metamodel, if you are using the default cm:content type or some custom ones.

As you said “in a certain folder”, I assumed above you wanted recursive parsing. If you don’t want that and simply want the direct content of a folder, then it’s much easier as you can just take the query from “All documents from a custom type with version history” and add an additional where clause to specify that the parent_node_id should be a specific value.

Regards,
Morgan

Hello,
Sorry but I didn’t get the question. Namespaces are related to metamodels (i.e. for example which kind of nodes you want to get, cm:content, cm:folder, custom types, …) while SpacesStore is related to the storage / file system where real document contents are. These 2 things have nothing in common so I’m not sure what you mean. As mentioned in some other comments, by default, a node using “workspace://SpacesStore” for the storage is the latest version of a document’s content while something that uses “workspace://version2Store” would be a previous version of a content.
Regards,
Morgan Patou

SELECT
n.id AS node_id
, concat(s.protocol,’://’,s.identifier,’/’, n.uuid) AS node_ref
, np1.string_value AS username
, np2.string_value AS email
FROM alf_node n
JOIN alf_store s ON (n.store_id=s.id)
— filter on type person
JOIN alf_qname qn ON (n.type_qname_id=qn.id AND qn.local_name=’person’
AND ns_id=(SELECT id FROM alf_namespace WHERE uri=’http://www.alfresco.org/model/content/1.0′)
)
— join property userName
left JOIN alf_node_properties np1 ON (n.id=np1.node_id
AND np1.qname_id =(SELECT id FROM alf_qname WHERE local_name=’userName’
AND ns_id=(SELECT id FROM alf_namespace WHERE uri=’http://www.alfresco.org/model/content/1.0′)
)
)
— join property email
left JOIN alf_node_properties np2 ON (n.id=np2.node_id
AND np2.qname_id =(SELECT id FROM alf_qname WHERE local_name=’email’
AND ns_id=(SELECT id FROM alf_namespace WHERE uri=’http://www.alfresco.org/model/content/1.0′)
)
)
ORDER BY np1.string_value;

Hi Collins,

I’m not sure I got the question. The query you mentioned comes from this blog in the section “Listing all groups and their membership”. As the name implies, this query will list all existing groups that have at least 1 member inside. There is no direct relation between authorities (groups/users) and permissions on their own. A group/user is assigned to a “role” (has permissions through an ACL) on a specific Node. But you need a node to have a link between an authority and a permission set.

To list permissions on a node, I also already provided a query under the section “Listing the permissions assigned to a specific Alfresco node”. I believe that’s what you wanted to see. You just select a Node ID (UUID) and execute this query for it. It will tell you which group/user has which access level on that specific node.

Regards,
Morgan

SELECT ca.parent_node_id AS "Parent ID",
ca.child_node_id AS "Child ID",
p.string_value AS "Group Name",
ca.qname_localname AS "User Name"
FROM alf_child_assoc AS ca,
alf_node AS n1,
alf_node AS n2,
alf_node_properties AS p
WHERE n1.id=ca.parent_node_id
AND n2.id=ca.child_node_id
AND p.node_id=n1.id
AND n1.type_qname_id IN (SELECT id FROM alf_qname WHERE local_name='authorityContainer')
AND n2.type_qname_id IN (SELECT id FROM alf_qname WHERE local_name='person')
AND p.qname_id IN (SELECT id FROM alf_qname WHERE local_name='authorityName')
ORDER BY p.string_value, ca.qname_localname;

Hi sergiobaiao,

For the query regarding all but the latest version, you have the needed details in this blog post already. If you take the query to list all documents bigger than 40Mb (for example) and execute it, you will see that the 2nd column “Store Name” changes and as it’s written in blog post and in the comment, “workspace://SpacesStore” is the latest version of the document while “workspace://version2Store” is an old version of a document. So you could select only the entries from the “version2Store” identifier column and that would normally be non-latest version of documents.

You should not remove versions from the database. As it was said in the discord, you should use API (REST-API or similar) to get the list of old versions of a document and delete them. If you don’t want to do it properly through API, for your space problem, a quick&dirty workaround could be to fetch all filesystem path for all non-latest versions of documents and replace the real content (on the alf-data folder) by a dummy one (e.g. an empty file – then reflect this in the metadata maybe?).

Regards,
Morgan

Can you please create a query that would show all but the latest versions of each document? And maybe one that removes all versions but the latest?

Hello,

The list of people who accessed the site or uploaded/downloaded documents within the site wouldn’t be available by default since the audit is turned off. It’s only if you have the audit enabled that this would be stored. If you have the audit enabled, then I would say that the way-to-go is to check the REST-API, c.f. https://docs.alfresco.com/content-services/latest/admin/audit/ && https://api-explorer.alfresco.com/api-explorer/… If you really want to use the DB, then it should be data from the alf_audit_* tables (in conjunction with other tables as shown in the blog to get properties and find out on which site it is). The DB isn’t really efficient for recursive things since Associations in Alfresco will only work with the direct parent folder. So if you want to look for all people who uploaded/downloaded from a Site, you need to find the Site Node, then list all its children and all their children’s children and all their children’s children’s children and etc…

For the total size/number of files in a Site, it’s the same as well… Doing the total for all Alfresco is easy, you just sum-up everything. But if you want only restricted to a specific Node (a Site being a certain Node), then it becomes quite complex because of the hierarchy/recursive problem. If you look at the section “Size and number of documents created by all users”, you can find some information on what could be done to evaluate the total size per user, but to restrict that to a certain Site, you would need to browse through all nodes 1 by 1 and sum-up their size, so if you have millions of nodes, it’s going to put a huge load on the DB. For the total number, you might find it easier to ask Solr with a PATH query using an Admin account, since that would be almost instantaneous and easy to execute.

You can also look at the “Recursively find the number of childs” section from the blog, which starts a query to find all the children and I believe that’s the starting point for all your queries, if you really want to do that through the DB.

Regards,
Morgan