[
https://issues.apache.org/jira/browse/OFBIZ-4709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13217130#comment-13217130
]
Sascha Rodekamp commented on OFBIZ-4709:
----------------------------------------
Good morning everybody
first sorry for my late response, believe it or not i was offline the hole
weekend :).
There is already a wiki page where i tried to document my current development
state. I will reorganize it, that we can store additional conceptional
documents. [https://cwiki.apache.org/OFBIZ/jackrabbit-branch-development.html]
{quote}
support searches such as "all documents of a certain type that have not expired"
{quote}
Jap we can do this. An example from the JCR Spec:
{quote}
A query can specify a constraint to filter the set of node-tuples by any
combination of:
* Value of a property, for example:
** Nodes whose jcr:created property is after 2007-03-14T00:00:00.000Z
* Existence of a property, for example:
** Nodes with a jcr:language property
{quote}
What I don't know yet,if either DB-Queries or JCR-Queries have the better
performance.
I agree with Jacques and Anne if we extend the contentTypeId it is not obvious
why we store the JCR indicator in this field. Otherwise i would let the
repository handle the different content types (We can use properties in the
nodes or create a certain content object mapping class).
Imagine you have a third party CMS system which should connect to the
repository to manage your contents, it's worse to implement a connector if you
have to mix up the ofbiz DB and the repository, but it's striate forward if you
only have the repository (assumed that the CMS uses JCR internally anyway).
If you like to switch to the ML fell free, initially i didn't expect a longer
discussion for this issue :-)
> Support jcr-stored file content within Applications
> ---------------------------------------------------
>
> Key: OFBIZ-4709
> URL: https://issues.apache.org/jira/browse/OFBIZ-4709
> Project: OFBiz
> Issue Type: Sub-task
> Components: ALL APPLICATIONS
> Affects Versions: SVN trunk
> Reporter: Anne Jessel
> Assignee: Sascha Rodekamp
>
> My current requirements:
> * store uploaded documents (pdf and scans), mainly for legal compliance
> reasons
> * old document versions should be accessible
> * documents should be associated with existing entities. So far I've
> identified a need to associate with Product, Party, OrderHeader,
> ShipmentItem, probably InventoryItemDetail and maybe WorkEffort. I would not
> be surprised if we discover more as this project proceeds.
> * documents may have a type and a purpose, though sometimes I'm not sure of
> the difference. For example, type: drivers_licence might be purpose:
> identification, and/or purpose: permission_to_drive, while type:
> shipping_label would be purpose: shipping_label
> * many documents have an expiry date (e.g. drivers licence)
> * a document may become invalid before its expiry date (e.g. because the law
> changed)
> * a specific version of a document may need to be associated with an entity.
> For example, a licence agreement document accessed via a Product should
> always be the latest version. However the version of that document actually
> shipped with the product should be associated with the ShipmentItem.
> * a single document might be associated with more than one entity type: see
> the example in the previous point
> Not all documents require all of the above. For example, there are some
> documents where we don't need to track which version was used when, and some
> without expiry dates.
> I'm thinking of using the from/thruDate pattern to handle expiry related
> needs. I'd like to put as much information into the jcr path as possible, so
> less needs to go into entities, as per Sascha's suggestion on the dev ML.
> However (at least) from/thruDate and which version of a document was actually
> used where will presumably need to be stored in an entity.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
