Persistence API

When year ago EMC announced the work under Persistence API for Documentum I started to worry about the future of their product stack (D2, xCP, etc) – who the hell needs xCP if you can create your own domain model and take advantage of modern frameworks like wicket, vaadin, etc? Fortunately, my concerns were not justified – EMC shared their work on github, and if even forget about the fact they they did nothing during last year:

I can definitely say that their implementation is a piece of shit. Interesting, what does EMC think about transactions? Nothing:

What does EMC think about following their recommendations? Nothing:

By the way I have started to work under JDO implementation for DFC, where code looks like:

<?xml version="1.0" encoding="UTF-8" ?>
<persistence xmlns="http://java.sun.com/xml/ns/persistence"
             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
             xsi:schemaLocation="http://java.sun.com/xml/ns/persistence
        http://java.sun.com/xml/ns/persistence/persistence_2_0.xsd" version="2.0">

    <persistence-unit name="Testing">
        <class>pro.documentum.model.DmUser</class>
        <exclude-unlisted-classes/>
        <properties>
            <property name="javax.jdo.option.ConnectionURL" value="dctm:DCTM_DEV"/>
            <property name="javax.jdo.option.ConnectionUserName" value="dmadmin"/>
            <property name="javax.jdo.option.ConnectionPassword" value="dmadmin"/>
            <property name="datanucleus.identityStringTranslatorType" value="dfidtranslator"/>
        </properties>
    </persistence-unit>
</persistence>
import java.util.Date;

import javax.jdo.annotations.Column;
import javax.jdo.annotations.PersistenceCapable;

import lombok.Getter;
import lombok.Setter;

/**
 * @author Andrey B. Panfilov <andrey@panfilov.tel>
 */
@PersistenceCapable(table = "dm_user")
public class DmUser extends AbstractPersistentObject {

	@Column(name = "user_name")
	@Getter
	@Setter
	private String userName;

	@Column(name = "user_os_name")
	@Getter
	@Setter
	private String userOSName;

	@Column(name = "user_address")
	@Getter
	@Setter
	private String userAddress;

	@Column(name = "user_group_name")
	@Getter
	@Setter
	private String userGroupName;
}


/**
 * @author Andrey B. Panfilov <andrey@panfilov.tel>
 */
public class TestJDO {

	@Test
	public void testName() throws Exception {
		PersistenceManagerFactory pmf = JDOHelper.getPersistenceManagerFactory("Testing");
		PersistenceManager pm = pmf.getPersistenceManager();
		Query query = pm.newQuery(DmUser.class, "(userName == :user_name || userLoginName == :user_name)");
		List<DmUser> results = (List<DmUser>) query.executeWithArray("dmadmin");
		assertNotNull(results);
		assertEquals(1, results.size());
		DmUser user = results.get(0);
		assertEquals("dmadmin", user.getUserName());
		assertEquals(16, user.getUserPrivileges());
        pm.close();
	}

}

and if you are interested in existence of robust Persistence API for Documentum let me know – I will share my work.

6 thoughts on “Persistence API

  1. It is indeed necessary to have an abstraction around some dfc functionality in Java.
    In our current project we have implemented following pieces:
    – DFC Session handling with spring annotations and Spring Method interceptors so that you can annotate your methods which need a dfc session and you don´t have to care about fetching and releasing a session. This works also nested and the interceptor takes care of different methods needing a dfc session. We also applied our best practices according dfc session manager and dfc sessions…
    – DFC transaction handling with spring annotation and Spring method interceptors which handles transactions the right way. It rollbacks the transaction when an exception is thrown and it will commit the transaction if there is no exception. This is decoupled from session handling, so that you are able to span several transactions for one dfc session (if you need to)
    – abstraction around query handling- we have implemented our own queryservice which takes are of correct dql parameter escaping to avoid dql injection, correct dql query handling (e.g. don´t use read queries) and a concept of a rowmapper where you only need to implement a mapping of dql result to a domain object. No worry about closing collections, looping results and all these stuff in our code anymore, it is handled centrally- no problem with Java 8 and lambdas.

    This helped us a lot to have clean code and to apply all best practices (and workarounds) around dfc in all parts of the code.

    Nevertheless I am interested in your jdo implementation. Can you share?

    Liked by 1 person

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s