[jira] [Created] (OFBIZ-4709) Support jcr-stored file content within Applications
Locked
12
12
[jira] [Created] (OFBIZ-4709) Support jcr-stored file content within Applications
 
|
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 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 |
[jira] [Assigned] (OFBIZ-4709) Support jcr-stored file content within Applications
|
|
[ https://issues.apache.org/jira/browse/OFBIZ-4709?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sascha Rodekamp reassigned OFBIZ-4709: -------------------------------------- Assignee: Sascha Rodekamp > 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 |
[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=13213488#comment-13213488 ] Sascha Rodekamp commented on OFBIZ-4709: ---------------------------------------- Hi Anne * store uploaded documents (pdf and scans), mainly for legal compliance reasons _Should already work_ *old document versions should be accessible _Should also already work_ *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. _There have to be somehow a connection between entities and jcr content._ *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 _Should this be stored in a content jcr node or do you think this have to be an entity field?_ *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) _Same question is it better to create a DB field or store the expire date along with the jcr nodes_ *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. _I think here we really need a DB connection, because the relation between a product and a certain version of a document could not be encoded in the jcr node_ *a single document might be associated with more than one entity type: see the example in the previous point Beside the node path it is possible to store information directly in the jcr node. Nodes with certain information could be selected by using SQL2 Querys which is already implemented in Jackrabbit. Another point which comes in my mind is rights management. Not sure if this is an issue in your case but we have to consider it. > 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 |
[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=13213488#comment-13213488 ] Sascha Rodekamp edited comment on OFBIZ-4709 at 2/22/12 9:38 AM: ----------------------------------------------------------------- Hi Anne * store uploaded documents (pdf and scans), mainly for legal compliance reasons _Should already work_ * old document versions should be accessible _Should also already work_ * 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. _There have to be somehow a connection between entities and jcr content._ * 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 _Should this be stored in a content jcr node or do you think this have to be an entity field?_ * 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) _Same question is it better to create a DB field or store the expire date along with the jcr nodes_ * 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. _I think here we really need a DB connection, because the relation between a product and a certain version of a document could not be encoded in the jcr node_ * a single document might be associated with more than one entity type: see the example in the previous point Beside the node path it is possible to store information directly in the jcr node. Nodes with certain information could be selected by using SQL2 Querys which is already implemented in Jackrabbit. Another point which comes in my mind is rights management. Not sure if this is an issue in your case but we have to consider it. was (Author: sascha): Hi Anne * store uploaded documents (pdf and scans), mainly for legal compliance reasons _Should already work_ *old document versions should be accessible _Should also already work_ *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. _There have to be somehow a connection between entities and jcr content._ *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 _Should this be stored in a content jcr node or do you think this have to be an entity field?_ *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) _Same question is it better to create a DB field or store the expire date along with the jcr nodes_ *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. _I think here we really need a DB connection, because the relation between a product and a certain version of a document could not be encoded in the jcr node_ *a single document might be associated with more than one entity type: see the example in the previous point Beside the node path it is possible to store information directly in the jcr node. Nodes with certain information could be selected by using SQL2 Querys which is already implemented in Jackrabbit. Another point which comes in my mind is rights management. Not sure if this is an issue in your case but we have to consider it. > 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 |
[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=13213488#comment-13213488 ] Sascha Rodekamp edited comment on OFBIZ-4709 at 2/22/12 9:42 AM: ----------------------------------------------------------------- Hi Anne * store uploaded documents (pdf and scans), mainly for legal compliance reasons _Should already work_ * old document versions should be accessible _Should also already work_ * 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. _There have to be somehow a connection between entities and jcr content, but i'm not sure what to put in the DB and which information in the node._ * 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 _Should this be stored in a content jcr node or do you think this have to be an entity field?_ * 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) _Same question, is it better to create a DB field or store the expire dates along with the jcr nodes_ * 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. _I think here we really need a DB connection, because the relation between a product and a certain version of a document could not be encoded in the jcr node_ * a single document might be associated with more than one entity type: see the example in the previous point Beside the node path it is possible to store information directly in the jcr node. Nodes with certain information can be selected by using SQL2 Querys which are already implemented in Jackrabbit. Another point which comes in my mind is rights management. Not sure if this is an issue in your case but we have to consider it. was (Author: sascha): Hi Anne * store uploaded documents (pdf and scans), mainly for legal compliance reasons _Should already work_ * old document versions should be accessible _Should also already work_ * 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. _There have to be somehow a connection between entities and jcr content._ * 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 _Should this be stored in a content jcr node or do you think this have to be an entity field?_ * 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) _Same question is it better to create a DB field or store the expire date along with the jcr nodes_ * 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. _I think here we really need a DB connection, because the relation between a product and a certain version of a document could not be encoded in the jcr node_ * a single document might be associated with more than one entity type: see the example in the previous point Beside the node path it is possible to store information directly in the jcr node. Nodes with certain information could be selected by using SQL2 Querys which is already implemented in Jackrabbit. Another point which comes in my mind is rights management. Not sure if this is an issue in your case but we have to consider it. > 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 |
[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=13214373#comment-13214373 ] Anne Jessel commented on OFBIZ-4709: ------------------------------------ Hi Sascha I agree with you. There will need to be entities to track the connections, so the key thing is what goes in an entity and what in a node. I'm thinking we will need several new entities such as PartyContentJcr and ProductContentJcr (suggestions for names welcome). Should these link directly to jcr nodes, or should there be a ContentJcr entity which represents the jcr node? I think a ContentJcr, so we can store (at least) from/thruDate there. But the reason I think that is because I am familiar with OOTB support for from/thruDate queries. I do not know jcr well enough: would these queries be just as efficient with the Jackrabbit SQL2 queries? Rights management is not an issue for me. But I am sure it will need to be added sometime. > 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 |
[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=13214408#comment-13214408 ] Jacopo Cappellato commented on OFBIZ-4709: ------------------------------------------ What about extending the Content entity to support JCR and then use the existing PartyContent/ProductContent etc... to specify the associations (as it is now)? > 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 |
[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=13214506#comment-13214506 ] Sascha Rodekamp commented on OFBIZ-4709: ---------------------------------------- Yes Jacopo, we should definitely the existing tables. I'm a little bit afraid, that to much content information will be stored in the database tables. But i see no way handling content without a connection to the DB so it's ok to use the content entities to manage it, if we have a DB lookup anyway we can use the from/thruDate filter. Anyway another point which comes to my mind. Would you disable the current product content storage? Or should we use the current entity based storage and the repository storage parallel? I think of saying the *ContentWorker which storage point he have to use (entity or repository). Means if someone want to use the DB, he can configure to use a ProductEntityContentWorker if he otherwise want to use the repository he can configure the ProductRepositoryContentWorker. The content Worker encapsulate all the access to the content store point. > 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 |
[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=13214514#comment-13214514 ] Pierre Smits commented on OFBIZ-4709: ------------------------------------- Perhaps it is a good idea to include end-of-life for current content storage somewhere in the roadmap, if the jcr approach proves to be more flexible and easier to use. This will help with communications and planning of phasing-out activities. Regards, Pierre Smits > 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 |
[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=13214529#comment-13214529 ] Jacopo Cappellato commented on OFBIZ-4709: ------------------------------------------ Sascha, I was thinking that, if for example we add a new contentTypeId of "JCR_CONTENT" (or similar), then all Content records with that type will use the external JCR repository, while the "old" Content records will still use the OFBiz DB; in this way the two mechanisms will fit together nicely. This is the general idea... as regards *ContentWorker specific implementation I don't know... some of the classes are rather old and not perfect but if it makes sense we could extend them to check the contentTypeId and use JCR if the type is JCR_CONTENT. > 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 |
[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=13214564#comment-13214564 ] Sascha Rodekamp commented on OFBIZ-4709: ---------------------------------------- Yap we need a separate content type: I would suggest JCR_CONTENT_* to differentiate between images, text, html and so on. {quote} *ContentWorker ... some of the classes are rather old and not perfect {quote} Right, but i don't like the idea to extend tho old code, because i think we can do much better. Leave the old class as it is and let us use a factory which decided which implementation for the specific content should be used (maybe depending on the content type). That gives us the ability to: 1.) create new clean code (and test drive it :)) 2.) make the DB and repository code independent (at some point in the feature we can simply remove one implementation) 3.) we haven't to worry to break anything from the exciting code |---can load--- *EntityContentWorker (implements ContentWorker) *ContentWorkerFactory ---- | |---can load--- *RepositoryContentWorker (implements ContentWorker) > 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 |
[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=13214564#comment-13214564 ] Sascha Rodekamp edited comment on OFBIZ-4709 at 2/23/12 11:48 AM: ------------------------------------------------------------------ Yap we need a separate content type: I would suggest JCR_CONTENT_* to differentiate between images, text, html and so on. {quote} *ContentWorker ... some of the classes are rather old and not perfect {quote} Right, but i don't like the idea to extend tho old code, because i think we can do much better. Leave the old class as it is and let us use a factory which decided which implementation for the specific content should be used (maybe depending on the content type). That gives us the ability to: 1.) create new clean code (and test drive it :)) 2.) make the DB and repository code independent (at some point in the feature we can simply remove one implementation) 3.) we haven't to worry to break anything from the exciting code | |---> can load ---> *EntityContentWorker (implements ContentWorker) |*ContentWorkerFactory ----> | | |---> can load ---> *RepositoryContentWorker (implements ContentWorker) was (Author: sascha): Yap we need a separate content type: I would suggest JCR_CONTENT_* to differentiate between images, text, html and so on. {quote} *ContentWorker ... some of the classes are rather old and not perfect {quote} Right, but i don't like the idea to extend tho old code, because i think we can do much better. Leave the old class as it is and let us use a factory which decided which implementation for the specific content should be used (maybe depending on the content type). That gives us the ability to: 1.) create new clean code (and test drive it :)) 2.) make the DB and repository code independent (at some point in the feature we can simply remove one implementation) 3.) we haven't to worry to break anything from the exciting code |---can load--- *EntityContentWorker (implements ContentWorker) *ContentWorkerFactory ---- | |---can load--- *RepositoryContentWorker (implements ContentWorker) > 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 |
[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=13214664#comment-13214664 ] Jacopo Cappellato commented on OFBIZ-4709: ------------------------------------------ Yes, it is fine to me, it will maybe require to change more code initially (all the code that is currently using *ContentWorker or *ContentWrappers methods) but it may be a nice refactoring. At the end, the important thing imo is to continue to use the Content and PartyContent/ProductContent... entities following a similar pattern: the actual implementation of util methods/wrappers can take several similar shapes. > 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 |
[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=13215192#comment-13215192 ] Anne Jessel commented on OFBIZ-4709: ------------------------------------ Thanks everyone for the comments. I like the direction this is heading. I think the treatment of contentTypeId needs more work. Currently this has values such as ANNOTATION, DECORATOR, TOPIC. Adding JCR_CONTENT_ANNOTATION and similar would make it difficult to find all the ANNOTATION content. Perhaps we should add an extra field to Content, called storageTypeId? It could have two possible values (at this stage) ENTITY or JCR, with default being ENTITY for backwards compatability. Also, Content entity doesn't currently have from/thruDate fields. I'll need to add those. > 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 |
[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=13215450#comment-13215450 ] Jacopo Cappellato commented on OFBIZ-4709: ------------------------------------------ Another option (but please consider that I am not looking at the details and I am simply providing some ideas) can be that of keeping the Content entity (and its data) as it is currently and then we define a new dataResourceTypeId (for JCR): Content (ANNOTATION, DECORATOR, etc...) --> DataResource (OFBIZ_FILE...) --> "old" content Content (ANNOTATION, DECORATOR, etc...) --> DataResource (JCR) --> JCR ("new" content) > 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 |
[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=13215526#comment-13215526 ] Sascha Rodekamp commented on OFBIZ-4709: ---------------------------------------- Hi, that means we will have a structure like: ProductContent --> Content --> DataSource --> JCR Repository (which have a tree of content nodes) That could tempt people to use ContentAssoc and all the fields in DataSource to store content information and arrange the content order. But i think that should be done in the repository, because otherwise we ignore the benefits of the jackrabbit repository and use it as simple datastore. My Suggestion is to keep the DB site as simple and flat as possible and let the repository do the rest.... Btw Anne, you can store the from/thruDate in the ProductContent entity which should be sufficient. > 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 |
Re: [jira] [Commented] (OFBIZ-4709) Support jcr-stored file content within Applications
|
In reply to this post by Nicolas Malin (Jira)
Le 24/02/2012 08:04, Jacopo Cappellato (Commented) (JIRA) a écrit :
> [ https://issues.apache.org/jira/browse/OFBIZ-4709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13215450#comment-13215450 ] > > Jacopo Cappellato commented on OFBIZ-4709: > ------------------------------------------ > > Another option (but please consider that I am not looking at the details and I am simply providing some ideas) can be that of keeping the Content entity (and its data) as it is currently and then we define a new dataResourceTypeId (for JCR): > > Content (ANNOTATION, DECORATOR, etc...) --> DataResource (OFBIZ_FILE...) --> "old" content > Content (ANNOTATION, DECORATOR, etc...) --> DataResource (JCR) --> JCR ("new" content) +1 all information on storage method need to present en dataResource not Content. This solution is pretty good :) > >> 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 > > |
[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=13215710#comment-13215710 ] Jacques Le Roux commented on OFBIZ-4709: ---------------------------------------- I did not look into details at all yet (hopefully this weekend). But I tend to agree with Sascha. A good reminder is this [Adam's "advocation" for a file system|http://markmail.org/message/nq2omr5p25v6lts6] It's a nightmare to udate contents (from staging to repo or any type of update) when they are in a DB... For contents think templates and such... > 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 |
[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=13215710#comment-13215710 ] Jacques Le Roux edited comment on OFBIZ-4709 at 2/24/12 4:05 PM: ----------------------------------------------------------------- I did not look into details at all yet (hopefully this weekend). But I tend to agree with Sascha. A good reminder is this [Adam's "advocation" for a file system|http://markmail.org/message/nq2omr5p25v6lts6] It's a nightmare to udate contents (from staging/QA to production or any type of update) when they are in a DB... For contents think templates and such... EDIT: === I used the word repo instead of production, it was a mistake, but it shows well my concern ;) === was (Author: jacques.le.roux): I did not look into details at all yet (hopefully this weekend). But I tend to agree with Sascha. A good reminder is this [Adam's "advocation" for a file system|http://markmail.org/message/nq2omr5p25v6lts6] It's a nightmare to udate contents (from staging to repo or any type of update) when they are in a DB... For contents think templates and such... > 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 |
[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=13216436#comment-13216436 ] Jacques Le Roux commented on OFBIZ-4709: ---------------------------------------- Ok I read the convo, and I'm still in favor of Sascha's global view. {quote} My Suggestion is to keep the DB site as simple and flat as possible and let the repository do the rest.... {quote} So Anne's suggestion of adding a storageTypeId field to Content Entity seems the best solution to me, so far. Anne, for the point: * a document may become invalid before its expiry date (e.g. because the law changed) You could use the Content.statusId field Unrelated, but I wanted to say that from/thruDate are cool, but not close to what a versioning system can offer... ---- *Mostly notes for myself* By and large (not only this issue), I must say that I'd like to think more about it. I mean to envision more scenarios, notably for handling Contents moves and udpates. And also activation (which version of a Content to use at a moment) not sure yet if it relates with activity concept in JackRabbit (in http://www.day.com/maven/jsr170/javadocs/jcr-2.0/javax/jcr/version/VersionManager.html, oops, for less than a second I did not remember Adobe had bought Day Software, ok not a pb still ASL2 anyway) OK also regarding Adam's comment I mentionned, I read http://wiki.apache.org/jackrabbit/PersistenceManagerFAQ and it's a more evolved than I thought, why a lot of Persistence Manager types and descripted strategies. > 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 |
«
Return to OFBiz - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |