Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [eclipselink-dev] Dynamic persistence unit

On 10/9/14 8:01 PM, Rick Curtis wrote:
> Ie it would be nice if the test could be written following way but I'm really not sure if that's doable and what pros/cons this approach would have - it's just an idea:
I too am not certain how doable it would be to use annotations rather than overridden methods. I can take a look though.

that would be great and it should not be difficult if the annotation would have  RetentionPolicy.RUNTIME. It could perhaps also get us on the path to make persistence.xml optional at some point - at least for some simple cases...


Have you had time to take a look yet? I'd like to get some sort of conscientious whether this change is something that I should move forward with.
yes, finally. I like the way it simplifies writing, building and running tests - no more "magic" buried in the build scripts, but the build part requires some work to be following the convention used through the project (ie using junit.lib property instead of referring to ECLIPSE_HOME as not all people working on EL do have Eclipse installed, making sure 'test' from cmd line works etc). OTOH I would still prefer if we could get rid of required inheritance from AbstractJPATest and allow people to inherit from whatever test/class they want if there's a need.

Thanks,
--lukas


On Wed, Oct 1, 2014 at 6:03 PM, Lukas Jungmann <lukas.jungmann@xxxxxxxxxx> wrote:
Hi Rick,

comments inline ...

On 10/1/14 11:11 PM, Rick Curtis wrote:
I finally had a few spare cycles the past couple days and put together a prototype test component. At this point all of this is flexible, but I want to get a feeling from others whether a change like this would be welcomed. I'll note that I did some hacking/poaching from the eclipselink.jpa.test build to get things working. I'm not a build guy, but I wanted to get something that generally works... so don't get too hung up on the build pieces.

as long as it works, it's fine at this stage and we have something 'real' to discuss :-)


My end goal is to have a framework that makes it very easy for someone to create a new jse JPA test. I want to stress that this new component won't be an end-all be-all test component.  The point of it is that anyone with JPA experience can easily and quickly create a JUnit test that can test a large majority of the runtime. That being said, there are certainly some aspects of the runtime that this component will not be able to test. 

A few things to note about this component :
* It uses a single static weaving configuration. That could change in the future if cases come up, but at this point it isn't necessary. When the tests run via ant Entities will be enhanced at compile time. You can also easily use the -javaagent to enhance while running in Eclipse.
* It is NOT targeted to run in an app server
* For most test cases a persistence unit defined in a persistence.xml is not required.
* It depends on eclipselink.ddl-generation for table generation.

Attached below are a couple patches that have the entire change, but I'll give a quick summary.

To create a new testcase :
* Define your Entity model. Entities/embeddables/etc must be in a *.model package
* Define a Test class (in a *.test package) that extends AbstractJPATest. You must implement the getManagedTypes() method to return the Entities that your testcase is using. This method is analogous to the <class> section in a p.xml.

 this leads me to the question - why not Maven - or at least not following its convention? I mean it has that convention to have 'real' classes in src/main/java, and tests in src/test/java and we have some model which we want to test..., one project per feature/bug,...- you get the point. I've tried to split current 'monolithic' e.core.test module this way already but had to put that aside for a while (as it is quite complicated/time-consuming due to many dependencies there). OTOH you are creating sth new, so maybe you could give it a try?

* Optionally override the getPersistentProperties() method to return an array of persistence properties your test might need to use.

 If this is a configuration thing, maybe some annotation instead of a method to be overridden would be better.

Ie it would be nice if the test could be written following way but I'm really not sure if that's doable and what pros/cons this approach would have - it's just an idea:


@PUConfig(
   props={@Property(name="eclipselink.log", value="FINE")},
   entities={ChildEntity.class, ParentEntity.class})
public class TestInheritancePrePersist {

    @Test
    public void testMultiplePrePersist() {
        EntityManagerFactory emf = AbstractJPATest.getEntityManagerFactory(TestInheritancePrePersist.class);
        ....
    }


Haven't tried your patches yet but hopefully will be able to give it a shot later this week..

thanks,
--lukas


* In each test method, there is an instance variable 'emf' that is based off the properties provided by your test class. 
* Test cases need to ensure that EMs are cleaned up properly
* AbstractJPATest should clean up tables after test classes complete, but it doesn't yet.

To run a new testcase:
* Either run the default target in eclipselink.test.jpa.jse, providing db connection details in test.properties
* To run in Eclipse, provide db connection details as SystemProperties -Djavax.blah bah

Example test :

public class TestInheritancePrePersist extends AbstractJPATest {
    @Override
    public Class<?>[] getManagedTypes() {
        return new Class<?>[] { ChildEntity.class, ParentEntity.class };
    }

    @Override
    public String[] getPersistentProperties() {
        return new String[] { "eclipselink.log", "FINE" };
    }

    @Test
    public void testMultiplePrePersist() {
        EntityManager em = emf.createEntityManager();
        try {
            em.getTransaction().begin();
            ChildEntity ce = new ChildEntity();
            em.persist(ce);

            em.getTransaction().commit();

            em.clear();
            Assert.assertEquals(1, ce.getPrePersistChild());
            Assert.assertEquals(1, ce.getPrePersistParent());
        } finally {
            if (em.getTransaction().isActive()) {
                em.getTransaction().rollback();
            }
            em.close();
        }
    }
...


Wow, that email got a lot longer than I intended. Anyway, I'm looking for a thumbs up / thumbs down on the direction I'm heading. If thumbs up, I'll start committing some code to master later this week.

Thanks,
Rick



On Wed, Sep 10, 2014 at 11:29 AM, Rick Curtis <curtisr7@xxxxxxxxx> wrote:
> 1. Byte-code weaving of the domain classes. In the standard class-loader configuration the domain classes will be woven once and only once. If this weaving is consistent across all persistence units and test that might share the domain class then you are fine but if the same class is used differently in different PUs then you will be challenged to have separate woven instances of the class isolated by the PU/test-case.

I figured this would be the case. I'm looking more at the middle of the road case. I assume a huge majority of cases can be covered with a default weaving configuration? That being said, I'm not very familiar with the EclipseLink weaving options to know how many different switches there are and how many of them are used in the wild.

> there is also the fundamental case that you are now testing a configuration that is separate from the JPA specified one.
True. Testing in this manner would exclude handling / parsing of p.xml files etc, but it would make adding tests for the rest of the runtime much simpler. 

> I do have a number of dynamic PU examples I had built locally that I will review and see how best to share.
I'd appreciate you sharing those. I assume these examples use features that are already a part of EclipseLink?

On Wed, Sep 10, 2014 at 10:35 AM, douglas clarke <douglas.clarke@xxxxxxxxxx> wrote:
Rick,

We have done a lot of work with respect to dynamic persistence units addressing both creating PUs on the fly based on concrete Java classes as well as scenarios where the domain classes themselves are created on the fly using byte-code generation.

There are two concerns I see with dynamic PUs for testing:

1. Byte-code weaving of the domain classes. In the standard class-loader configuration the domain classes will be woven once and only once. If this weaving is consistent across all persistence units and test that might share the domain class then you are fine but if the same class is used differently in different PUs then you will be challenged to have separate woven instances of the class isolated by the PU/test-case.

2. We did look at a number of ways to simplify this early on including a custom property for where the persistence.xml file is read from so that we could have a flat classpath for all test cases and supporting PUs. Besides the weaving issue in #1 there is also the fundamental case that you are now testing a configuration that is separate from the JPA specified one. This may be acceptable if managed correctly and there are adequate 'pure JPA' test cases in addition to the compliance tests.

I do have a number of dynamic PU examples I had built locally that I will review and see how best to share.

Doug



On 2014-09-09, 9:17 PM, Rick Curtis wrote:
All -

For a while now, I have wanted an easier way to test EclipseLink and tonight I finally found a few spare cycles to look at this problem. I have been looking for a way to easily create a persistence unit that only exists for the scope of an individual test. I did some poking around and found that without too many changes, I could update JPAInitializer so that a user to could create a SEPersistenceUnitInfo and pass that in as a persistence property on a .createEntityManagerFactory(....) call. This means that you could create an EMF without the requirement of having a p.xml file... the largest drawback I can see at this point is that this data structure is marked as internal, so I don't know if it is kosher to expose outside of the runtime.

Thoughts on going down this road? If I don't hear anything negative, I'll get a bug opened soon and post an initial patch.

--
Rick Curtis


_______________________________________________
eclipselink-dev mailing list
eclipselink-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/eclipselink-dev


_______________________________________________
eclipselink-dev mailing list
eclipselink-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/eclipselink-dev



--
Rick Curtis



--
Rick Curtis


_______________________________________________
eclipselink-dev mailing list
eclipselink-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/eclipselink-dev


_______________________________________________
eclipselink-dev mailing list
eclipselink-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/eclipselink-dev



--
Rick Curtis


_______________________________________________
eclipselink-dev mailing list
eclipselink-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/eclipselink-dev

Back to the top