]
Brett Meyer resolved ARTIF-689.
-------------------------------
Resolution: Done
Remove the JCR persistence adapter
----------------------------------
Key: ARTIF-689
URL:
https://issues.jboss.org/browse/ARTIF-689
Project: Artificer
Issue Type: Task
Reporter: Brett Meyer
Assignee: Brett Meyer
Fix For: 1.1.0.Final, 1.0.0.Beta1
ARTIF-683 switched to a JPA/RDBMS default persistence strategy. Originally, we intended
to keep the JCR plugin and continue to maintain it, however:
First and foremost, initial performance tests are looking extremely promising. With the
exception of uploads (slower for JPA due to Hibernate Search indexing and complicated
INSERTs, as opposed to JCR node creation), everything else is 2-5x faster, including
complex queries.
Further, I'm starting to hit certain dependency conflicts between Hibernate and
ModeShape that might eventually require a split in Artificer distros. Maintaining both is
already becoming a headache.
Is there much of a point in keeping both? The only argument I can think of is if for
some reason a user was integrating S-RAMP's JCR storage with their existing,
*non-RDBMS* source (Cassandra, etc) through ModeShape/Infinispan. But that's highly
unlikely. In my mind, everything else trumps the off-chance for backward compatibility
issues. Most users we talk to see JCR purely as an implementation detail.
We will, however, provide a migration strategy. It would simply be code fragments from
both adapters, translating to and from the backends. Honestly simple stuff.