[JBoss JIRA] (ARTIF-691) Create an S-RAMP import/export utility
by Brett Meyer (JIRA)
Brett Meyer created ARTIF-691:
---------------------------------
Summary: Create an S-RAMP import/export utility
Key: ARTIF-691
URL: https://issues.jboss.org/browse/ARTIF-691
Project: Artificer
Issue Type: Feature Request
Reporter: Brett Meyer
Assignee: Brett Meyer
Create an Atom API client utility that allows import/export between S-RAMP implementations. This will be helpful in general. But currently important, it will allow migration to the new backend.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years
[JBoss JIRA] (ARTIF-690) Switch to CMT JTA
by Brett Meyer (JIRA)
Brett Meyer created ARTIF-690:
---------------------------------
Summary: Switch to CMT JTA
Key: ARTIF-690
URL: https://issues.jboss.org/browse/ARTIF-690
Project: Artificer
Issue Type: Enhancement
Reporter: Brett Meyer
Assignee: Brett Meyer
Rather than simply using JDBC transactions at the persistence level, switch to using CMT JTA at the REST/EJB level.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years, 1 month
[JBoss JIRA] (ARTIF-689) Remove the JCR persistence adapter
by Brett Meyer (JIRA)
Brett Meyer created ARTIF-689:
---------------------------------
Summary: 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
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.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years, 1 month