OFBiz › OFBiz - Dev

[jira] [Created] (OFBIZ-4709) Support jcr-stored file content within Applications

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

30 messages Options

Nicolas Malin (Jira)

[jira] [Commented] (OFBIZ-4709) Support jcr-stored file content within Applications

[ https://issues.apache.org/jira/browse/OFBIZ-4709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13216460#comment-13216460 ]

Jacopo Cappellato commented on OFBIZ-4709:
------------------------------------------

Well, I am not sure if Anne's proposal is in the direction of a flatter db structure; she mentions the need to have storageTypeId=JCR and several contentTypeId (ANNOTATION, DECORATOR etc...) all maintained in the Content data model.
If we instead use a flat contentTypeId=JCR and then delegate to JCR to manage the type of content etc. we will have mostly everything on JCR (if contentTypeId is JCR) and still have the ability to use traditional content... but of course this is too generic because I actually didn't look at the details and I am not even sure I know what are all the requirements and goals of this effort.

> 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

Nicolas Malin (Jira)

[jira] [Commented] (OFBIZ-4709) Support jcr-stored file content within Applications

In reply to this post by Nicolas Malin (Jira)

[ https://issues.apache.org/jira/browse/OFBIZ-4709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13216508#comment-13216508 ]

Adrian Crum commented on OFBIZ-4709:
------------------------------------

Is there a design document somewhere? I mean for this integration. That document should list the design criteria, objectives, deliverables, etc.

Nicolas Malin (Jira)

[jira] [Commented] (OFBIZ-4709) Support jcr-stored file content within Applications

In reply to this post by Nicolas Malin (Jira)

[ https://issues.apache.org/jira/browse/OFBIZ-4709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13216687#comment-13216687 ]

Jacques Le Roux commented on OFBIZ-4709:
----------------------------------------

To be fair, in my mind I was not referring to Anne's specific problem. But to her generic solution (Content.storageTypeId) mixed with a proposition based on Sascha's initial proposition of using a ContentFactory (he spoke about *ContentWorkerFactory). This to instantiate the respective "DataSource types".

In other words we would use a ContentFactory Interface (or Abstract Class) to delegate the work to concrete classes DbContentFactory or JcrContentFactory, ...

But indeed it's maybe easier to cut up the steam with a contentTypeId="JCR". I just wonder if it will not be to much confusing because it's no really a content type but a family of content types. Hence the Content.storageTypeId, where we could also decide of the JackRabbit Persistence Manager:
storageTypeId = OFBizDB (standard)
storageTypeId = jackrabbitDerbyPersistenceManager (
storageTypeId = jackrabbitPostgreSQLPersistenceManager
storageTypeId = jackrabbitMySqlPersistenceManager
storageTypeId = jackrabbitBundleFsPersistenceManager
storageTypeId = jackrabbitinMemPersistenceManager
storageTypeId = jackrabbitSimpleDbPersistenceManager
etc.

Just ideas threw out at this stage, I feel it misses more thoughts and maybe mixed to aspects (type and persistence). Also I'm far to undersand all the JCR aspects. I will begin by reviewing ExampleJackrabbitShowContentData today...

BTW maybe we/I should not continue to pollute Anne's topic and to create another Jira or rather continue to discuss this on dev ML?

My 2cts

Nicolas Malin (Jira)

[jira] [Commented] (OFBIZ-4709) Support jcr-stored file content within Applications

In reply to this post by Nicolas Malin (Jira)

[ https://issues.apache.org/jira/browse/OFBIZ-4709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13216688#comment-13216688 ]

Jacques Le Roux commented on OFBIZ-4709:
----------------------------------------

Mmm, it seems that in putting the cart before the horse. PersistenceManager is internal to JackRabbit and part of the Workspace, much more to learn...

Nicolas Malin (Jira)

[jira] [Issue Comment Edited] (OFBIZ-4709) Support jcr-stored file content within Applications

In reply to this post by Nicolas Malin (Jira)

[ https://issues.apache.org/jira/browse/OFBIZ-4709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13216688#comment-13216688 ]

Jacques Le Roux edited comment on OFBIZ-4709 at 2/26/12 10:20 AM:
------------------------------------------------------------------

Mmm, it seems that in I'm putting the cart before the horse. PersistenceManager is internal to JackRabbit and part of the Workspace, much more to learn...

was (Author: jacques.le.roux):
Mmm, it seems that in putting the cart before the horse. PersistenceManager is internal to JackRabbit and part of the Workspace, much more to learn...

Nicolas Malin (Jira)

[jira] [Commented] (OFBIZ-4709) Support jcr-stored file content within Applications

In reply to this post by Nicolas Malin (Jira)

[ https://issues.apache.org/jira/browse/OFBIZ-4709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13217004#comment-13217004 ]

Anne Jessel commented on OFBIZ-4709:
------------------------------------

Thanks all for the excellent feedback.

Like many of you, I also like to have little data in the entities, and most in Jackrabbit. I would prefer to ignore the existing DataResource for this.

I don't like storing a document's expiry date as from/thruDate in ProductContent, because one document could be associated with multiple Product, Party, ShipmentItem etc entity values. The same from/thruDate would have to be copied to all of these. To me, the from/thru in something like a ProductContent entity states when the association between the content and the product is valid, not when the content itself is valid. The difference doesn't really matter if a specific content is always related to only one product.

If Jackrabbit can efficiently and easily support searches such as "all documents of a certain type that have not expired" then I'd prefer to put the expiry date in Jackrabbit. But if the OOTB entity system does a better job (as I suspect), then I'd rather expiry be in an entity. Anyone know which is more efficient?

I think Jacopo misunderstood what I said about contentTypeId having values such as ANNOTATION. I don't wish to add those. That is what is there now. I was trying to say that I think the existing use of contentTypeId is not compatible with indicating whether content is stored in JCR or Entity, therefore I suggest we add a new field for that purpose, namely storageTypeId.

Adrian asked whether there is a design document somewhere. No there isn't (except my scratches on paper). Do you think I should add a page on the wiki or something? I don't mind where we discuss this: I started on the ML, and was advised to move it to Jira, but maybe it has evolved such that Jira is no longer appropriate. It is time I did a summary of my understanding of the current consensus anyway, so let me know where you all would prefer me to put it.

Nicolas Malin (Jira)

[jira] [Commented] (OFBIZ-4709) Support jcr-stored file content within Applications

In reply to this post by Nicolas Malin (Jira)

[ 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 :-)

Nicolas Malin (Jira)

[jira] [Commented] (OFBIZ-4709) Support jcr-stored file content within Applications

In reply to this post by Nicolas Malin (Jira)

[ https://issues.apache.org/jira/browse/OFBIZ-4709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13217137#comment-13217137 ]

Jacopo Cappellato commented on OFBIZ-4709:
------------------------------------------

Thank you Sascha.
The architecture document is good but would I would like to see is a gap analysis between the features of the current Content framework in OFBiz that are currently used versus the new JCR mechanism.

I am not asking you to document all of this, but I think it is important that we all discuss and understand all pros and cons.

Main questions to answer are:
* what are the mandatory features of the current Content and how will be implemented/migrated in the new implementation? Here a POC to show how different OFBiz content related setup will be in the new system would really help: for example how to associate localized content to a Product by purpose

As soon as we will have a clear understanding of how, in the new framework, we will implement the features that we consider mandatory, it will be much easier to focus the effort in completing this work.

Nicolas Malin (Jira)

[jira] [Commented] (OFBIZ-4709) Support jcr-stored file content within Applications

In reply to this post by Nicolas Malin (Jira)

[ https://issues.apache.org/jira/browse/OFBIZ-4709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13218011#comment-13218011 ]

Sascha Rodekamp commented on OFBIZ-4709:
----------------------------------------

Hi, jap that seems to be a good starting point. I will come up with a proposal in the next days. If anyone have time to publish a document earlier... feel free.

BTW i restructured the [wiki page|https://cwiki.apache.org/OFBIZ/jackrabbit-branch-development.html] so we should place all documents and design decisions there.

Nicolas Malin (Jira)

[jira] [Commented] (OFBIZ-4709) Support jcr-stored file content within Applications

In reply to this post by Nicolas Malin (Jira)

[ https://issues.apache.org/jira/browse/OFBIZ-4709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13218929#comment-13218929 ]

Anne Jessel commented on OFBIZ-4709:
------------------------------------

Thanks for restructuring the wiki page, Sascha. It will be easier to expand on now.

I planned to add some draft design ideas today, but instead I have come up with lots of questions. I realised I don't understand well enough how you intended the existing JCR classes to be used. I am adding here some of my thoughts: hopefully that will help make it all clearer to me and maybe others.

I can think of two general use cases (ignoring standard CRUD-type operations):

* I have already information that specifies which content I want. For example, I have a PartyContent or ProductContent entity, and want the associated content.
* I need to choose specific content based on certain criteria. For example, I want to display a list of available and current Data Sheets to the user. When the user chooses one, I will link it to a Product by creating a ProductContent.

Initially I had in mind a general workflow as follows:

# use current entity support to find desired Content entity (or maybe just contentId)
# pass chosen Content entity (or contentId) to a ContentFactory class method
# ContentFactory returns an object of an Interface type, with specific implementation determined by (at least) storageTypeId.
# code that invoked ContentFactory uses methods of Interface to access actual content and its metadata, and does not need to know whether the content and metadata is from other Entities, or from JCR

If we do this, the design of the Interface returned by the ContentFactory will be very important.

If the orm classes and Jackrabbit annotations are used, I'm not sure how best to make use of Content entity in a generic way. Maybe there needs to be a different orm.jackrabbit class, and corresponding api.*Helper, for each ContentType? And the ContentFactory uses the contentTypeId field to work out what class to instantiate (but only when storageTypeId is JCR).

If we store searchable metadata such as from/thruDate and contentType in JCR, then maybe we can't always do workflow step 1 the way I was thinking. Maybe we need also a ContentWorker that will do searches for us, and automatically knows how to search both Entities and JCR repository?