我正在构建一个基于JSF-Spring-Hibernate的应用程序，它需要将内容存储为pdf，MS Office文件等。我正在考虑提供JCR功能，添加Jackrabbit或Modeshape，但是我仍有一些疑问。
我们实际上将内容作为原始文件存储在文件系统中，并向我们的MySql数据库添加引用。该DB表还保留了有关修改，版本等的信息。拥有它可以很容易地检索每组，每个用户等上传文件的数据。使用JCR API这么直接吗？此外，是否有可能将文件保存在文件系统中并将元数据信息存储到MySQL中，因为我们实际上正在使用JCR？
由创建的 - 由字段更新实际存储在数据库表中并引用到我的应用程序中的系统用户，但JCR实现似乎有自己的认证系统。我在这里提出的方法是创建一个新用户进入系统的每个用户的JCR实现？那么密码更新呢？是否建议保持用户系统密码与存储库中的密码同步？或者是否应该为每个用户使用相同的密码进入存储库？
我们经常使用多种语言处理相同的文档。在这种情况下，文档版本是相同的，但文件之间的语言不同。我已经看到规格中有 jcr：language 属性，可以用它吗？
我可以看到另一个可能的问题是我们目前没有在我们的群组名称中控制名称重复。可能有两个相同的组名，并且将它们的目录与文件系统不同，我们使用它们的DB id附加到目录路径中的名称。我不知道这是否真的是一种最佳实践，我们如何通过JCR实现来管理它...
PD：我的servlet容器是Tomcat 6.
汇集您的想法！
答案 0 :(得分：2)
您已声明您已经依赖Hibernate和MySQL来存储大部分数据并将文件存储在文件系统中。你有什么希望JCR带来的？什么是关于Hibernate，MySQL和/或文件系统还不够？您当前的架构难以扩展或集群吗？编写同一个文件时是否存在并发问题？您的实体类是否具有限制性？你是实体形成一个层次结构，因为这对Hibernate和关系数据库来说通常很难吗？
您必须考虑更改当前架构以添加全新的数据存储技术。
让我们假设您只想将文件内容存储在JCR存储库中而不是文件系统中。是的，这样可行，并且它可能会简化您的应用程序并使用更少的代码更容易。但这种好处是否值得为您的应用程序添加JCR实现的复杂性？ （只有你可以回答这个问题。）
或者您是否也考虑使用JCR而不是Hibernate。有些人发现很难想象，但在某些情况下（特别是当你的实体主要是类似地图的数据结构时），JCR实际上可以比Hibernate更加干净地存储信息。
将数据存储在JCR中意味着每个“实体”都用节点和属性（以及可能是更复杂实体的子节点）表示，并且这些实体将存储在分层结构中。您可以在使用通用节点类型（如nt:unstructured）时执行所有这些操作，也可以选择为每种类型的实体定义节点类型。使用mixin类型和剩余属性定义，您甚至可以允许单个类型的实体的节点在它们保存的信息类型上有所不同：所有客户节点可能包含客户ID，名字，姓氏和其他一些位信息，但一些客户有额外的信息（会员ID，memberSinceDate等），您只需要添加到适当的客户节点。随着您的需求随着时间的推移而变化，存储在节点上的数据可以轻松地随之发展，有时甚至无需修改您的节点类型（BTW，可以动态完成而无需重新启动应用程序，或者如果您提前计划而不需要更改您的应用程序代码。）
简而言之，即使在开发应用程序之后，使用JCR作为数据库也可以提供极大的灵活性。它使您不必为数据实体定义具有固定字段的显式类，并且它允许您的应用程序更关注适合特定实体实例的信息。
总之，仅仅使用JCR存储文件可能有点过分 - 听起来你已经有了存储文件元数据的实体。您描述您的架构的方式，您不会真正受益于JCR的任何最佳功能。这让我觉得JCR根本不适合您当前的架构 - 您似乎已经实现了大部分功能。