Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    bkalbfus
    @bkalbfus
    When I put a test into my test project, it works like expected. I'm thinking it may have to do with the branch of execution it is running in the CollectionContainsMethod class.
    bkalbfus
    @bkalbfus
    I found that setting the parameter to an array of the primitive int or long data type causes the error. I have the error condition primed in my test project at https://github.com/bkalbfus/test-jdo/blob/33f2dd94cf4051258de2d05e2eb52b35d30f8aa0/src/test/java/org/datanucleus/test/ArrayParamTest.java#L62
    bkalbfus
    @bkalbfus
    A related question: how do I represent a NOT IN filter?
    SELECT * FROM myTable where myTable.id NOT IN (1, 3, 6, 12, 33)
    My first hunch was to negate the BooleanExpression from the contains filter. That gave me an error:
    java.lang.UnsupportedOperationException: Dont currently support operator - in JDOQL conversion
        at org.datanucleus.api.jdo.query.AbstractJDOQLTypedQuery.getJDOQLForExpression(AbstractJDOQLTypedQuery.java:519)
    Andy Jefferson
    @andyjefferson
    Please dont use SQL equivalents, this is JDOQL which has its own (string) syntax using Java syntax; the sooner you adapt to that the better - quoting the string JDOQL form would be a way better way to proceed. As already said, you can use "contains", and so if you want to negate that you call "not()" on the contains expression. Works for me, and in the same way I can create a parameter of type List with Integer elements and that works for me too. If it doesn't for you then you need to debug your usage, and get the DN code.
    Andy Jefferson
    @andyjefferson
    Calling Arrays.asList() and passing in an int[] creates a List of int[] elements. Perhaps you don't mean to do that. #usererror
    bkalbfus
    @bkalbfus
    I would call such behavior in Arrays.asList a bug. That or a big violation of sense! Won't be the first. Thanks for the tip!
    bkalbfus
    @bkalbfus
    Using the JDOQLTypedQuery, I appended .neg() to the contains filter and got the error I quoted above. Test project is updated, please see here
    I assume that calling .neg on a BooleanExpression would be equivalent to wrapping the JDOQL boolean expression in not()
    bkalbfus
    @bkalbfus
    all good now. My code completion tool didn't give me the .not() method when I looked at first, so I guessed that .neg() was what I was looking for. Thanks! #usererror
    Andy Jefferson
    @andyjefferson
    There is no explicit callback for makeTransient. JDO defines its callbacks clear enough. There is a postLoad.
    Marco Lopes
    @marcolopes
    Hi Andy. Problem is "postLoad" is NOT triggered by a query!!! :\ I'm using postDetach to catch DETACHED query results... but i have queried instances that are NOT detached (they are made transient...). I don't mind catching them any other way... but how??
    Andy Jefferson
    @andyjefferson
    Works for all JDO TCK tests. Works for all DN tests. All are public.
    Marco Lopes
    @marcolopes
    well, then DN 2.1 RELEASE is buggy in this respect, because it does not work (or is it dependent on any PMF configuration!?)
    Marco Lopes
    @marcolopes
    i have made a TEST CASE with "plain" configuration, and the postLoad listener works... :\ Can it be some PMF config that is messing this up?
    Marco Lopes
    @marcolopes
    I'm going nuts with this! Turning ON (default) LEVEL 2 CACHE makes the postLoad work on some queries, but not all and not under all scenarios! Cannot make sense of this...
    Marco Lopes
    @marcolopes
    Testing with DN 3.3.0 and with SAME code used with DN 2.1.0 i get "javax.jdo.JDOUserException: Configuration changes are not allowed on this PMF, since either it was generated using a JDOHelper factory method, or persistence managers have been generated"
    Marco Lopes
    @marcolopes
    Andy, i found the problem after many debug hours... THE FETCHPLANS are affecting the way the LISTENERS are triggered. Can you explain me why? I create "dynamic" fetchgroups, according to the fields i need to query... how can that interfere with the listener?
    Marco Lopes
    @marcolopes
    Apparently i'm not allowed to do pm.getFetchPlan().clearGroups()
    If i clear the "default" group, the postLoad listener is not executed...
    i'm totally puzzled...
    Andy Jefferson
    @andyjefferson
    What v2.1 and v3.3 do I couldn't care less. Current codebase is the only thing in play in this support area.
    Marco Lopes
    @marcolopes
    ok Andy, but can you tell me IF the expected behavior in DN is: The DEFAULT fetchgroup must be present in the PM so that the listeners can work with the queries?
    There is something puzzling me, and i cannot find it on the DN docs (even 5.x): Can i programmatically manipulate the "default" fetchgroup (PMF and/or PM wise) so that o can ADD / REMOVE members ? Or is the "default" fetchgroup bounded to the metadata definition?
    Andy Jefferson
    @andyjefferson
    Default fetch group is DEFINED by metadata. I've absolutely no idea why anyone would even want to change it. Users have their own fetch groups if they want to define other groupings.
    Marco Lopes
    @marcolopes
    Andy, i just want to avoid the default fetch group from interfering in the fetchplan i define programmatically... so, i remove it from the fetchgroups of the PM or i change it! There are some operations that i want the default fetch to kick in (so, it is), but others that i don't want the default fetchgroup to interfere!
    I will try to test my code with v4 or 5 of DN (i'm having problems because the JDO api is not found... the usual problems under OSGI)
    Marco Lopes
    @marcolopes
    Testing DN 4.x and 5.x i get "Error : Could not find API definition for name "JDO".
    All jars are in the classpath together with JDO javax. No differences here from my production env with DN 2.1
    Marco Lopes
    @marcolopes
    ALSO, when using DN 4.2 with JAVA 7, i get "java.lang.UnsupportedClassVersionError: org/datanucleus/store/types/java8/wrappers/ArrayList : Unsupported major.minor version 52.0" when using the enhancer...
    the docs http://www.datanucleus.org:15080/products/accessplatform_4_2/ say JRE required : 1.7 or above
    pretty much lost here
    Feb 23, 2019 3:57:29 AM org.datanucleus.plugin.NonManagedPluginRegistry getManifestURL
    WARNING: Could not find MANIFEST.MF file for plugin file "bundleresource://63.fwk29199470/plugin.xml" so ignoring it
    Feb 23, 2019 3:57:29 AM org.datanucleus.plugin.NonManagedPluginRegistry getManifestURL
    WARNING: Could not find MANIFEST.MF file for plugin file "bundleresource://63.fwk29199470/plugin.xml" so ignoring it
    Feb 23, 2019 3:57:29 AM org.datanucleus.api.ApiAdapterFactory getApiAdapter
    SEVERE: Error : Could not find API definition for name "JDO". Perhaps you dont have the requisite datanucleus-api-XXX jar in the CLASSPATH?
    Andy Jefferson
    @andyjefferson
    If "all jars are in the classpath" then you can easily provide a testcase as per http://www.datanucleus.org/documentation/problem_reporting.html#jdo
    DN 4.x is not supported as already said; only DN 5.1 and 5.2 are supported.
    Andy Jefferson
    @andyjefferson
    Also org/datanucleus/store/types/java8/wrappers/ArrayList only exists in datanucleus-java8.jar in the 4.x timeline, so why are you including that in your classpath if you say you are using Java 7???!!! https://github.com/datanucleus/datanucleus-java8/tree/master/src/main/java/org/datanucleus/store/types/java8/wrappers
    Marco Lopes
    @marcolopes
    Removed datanucleus-java8-4.2.0-release from dependencies and i can run the enhancer now... still, running the app throws the "org.datanucleus.exceptions.NucleusUserException: Error : Could not find API definition for name "JDO". Perhaps you dont have the requisite datanucleus-api-XXX jar in the CLASSPATH?". The fight goes on...
    Marco Lopes
    @marcolopes
    Tried everything i could think of... even looked at the 5.x docs about ECLIPSE OSGI runtime to see if something has changed from 2.x / 3.x to 4.x / 5.x, but i can't see any changes. I still have to install all the DN dependencies as Eclipse Plugins, and pass the "org.datanucleus.api.jdo.JDOPersistenceManagerFactory" CLASS LOADER to the getPersistenceManagerFactory(props, pmfClassLoader)
    so, nothing to change here... still, JDO API is not found. Can't even try DN 4 under my test platform.
    Marco Lopes
    @marcolopes
    @andyjefferson, the method getObjectById is considered a LOAD from the database, right? It should trigger the postLoad method of the LoadLifecycleListener interface, right? The docs only say "Invoked whenever a persistent instance is loaded from the data store", and i'm confused, because it does not trigger anything...
    Andy Jefferson
    @andyjefferson
    getObjectById does NOT necessarily mean ANY round trip to the database; why not actually look at the log?. A load is when fields are needed. Any postLoad is indeed called when the fetch plan is loaded, as per the JDO spec. No testcase demonstrates anything to the contrary
    Marco Lopes
    @marcolopes
    Well, i did a test case with DN 2.1, and i found the reason why i the behavior changed in my app: because the Queries would not trigger the postLoad without the DEFAULT FETCHgroup being in the fetchplan, i changed the whole logic, and defined all the classes with ONLY THE KEY field being in the DEFAULT fetchgroup. After that, i just keep the DEFAULT fetch group (aka, the KEY field!) and add other groups in runtime to achieve the desired effect on queries... PROBLEM!!!!! When i do a simple getObjectById of those objects now, they DON'T trigger the postLoad!!! I need to define another FIELD apart from the KEY one to achieve that!... Andy... I advise DN or JDO to revise the way this works or to update the DOCS with these unknown scenarios so that the users can take a valid approach in the implementation... now i have to think of a new approach...
    Andy Jefferson
    @andyjefferson
    Final time : if you have some persistence code that creates a problem (with or without capitals), then just demonstrate it with a testcase and then precise details of what you mean are defined. Given your past history of never providing a testcase I won't hold my breath for that. Apache JDO is where you raise problems with capabilities of the JDO spec. Bye
    Steve Springett
    @stevespringett

    I’ve run into a blocking issue when attempting to upgrade from 5.1.9 to 5.2.0 and have narrowed it down to a change that was made between 5.1.9 and 5.1.10. So upgrading from 5.1.9 to 5.1.10 also does not work. Specifically I use http://www.datanucleus.org/products/accessplatform/jdo/mapping.html#valuegen_uuid and it appears that it doesn’t properly work with this change datanucleus/datanucleus-rdbms@7c75854 - at least that’s what appears to be happening - debugging DN can be challenging when you’re not familiar with the inner-workings.

    All along my UUID classes have used the following format:

    @Persistent(customValueStrategy = "uuid")
    @Unique(name = "TEAM_UUID_IDX")
    @Column(name = "UUID", jdbcType = "VARCHAR", length = 36, allowsNull = "false")
    @NotNull
    private UUID uuid;

    However, I have also tried the following with the same result

    @Persistent(customValueStrategy = "uuid-object")
    private UUID uuid;

    A NPE is thrown in both cases.

    java.lang.NullPointerException
        at org.datanucleus.store.rdbms.mapping.java.UUIDMapping.setObject(UUIDMapping.java:141)
        at org.datanucleus.store.rdbms.sql.SQLStatementHelper.applyParametersToStatement(SQLStatementHelper.java:310)
        at org.datanucleus.store.rdbms.query.JDOQLQuery.performExecute(JDOQLQuery.java:623)
        at org.datanucleus.store.query.Query.executeQuery(Query.java:1967)
        at org.datanucleus.store.query.Query.executeWithArray(Query.java:1856)
        at org.datanucleus.api.jdo.JDOQuery.executeInternal(JDOQuery.java:433)
        at org.datanucleus.api.jdo.JDOQuery.execute(JDOQuery.java:276)
        at alpine.persistence.AbstractAlpineQueryManager.getObjectByUuid(AbstractAlpineQueryManager.java:518)

    Am I doing something wrong? Are there any working unit tests for this? I could only spot a single unit test in the rdbms module, so i assume if tests exist they are in another module. I need a 36 character UUID object for these fields and currently haven’t been able to achieve that with 5.1.10 and higher. Any pointers much appreciated.

    Andy Jefferson
    @andyjefferson
    The normal thing to do with an NPE is work out WHAT is null, and then you can understand why, what situation (of yours) is not catered for, and what fix to contribute. That change is amply documented (IMHO) in the issue tracker, and yes I have a test that it fixes. Clearly I don't have tests for your situations, but then that is why people have been advised to contribute to this project since 2003.
    Andy Jefferson
    @andyjefferson
    You only need to look at one class to debug the code ... UUIDMapping. UUID value generation tests are in jdo/identity as well as basic UUID tests in jdo/general, as well as my own tests (private).
    Steve Springett
    @stevespringett
    Well, seeing what’s null is easy. https://github.com/datanucleus/datanucleus-rdbms/blob/master/src/main/java/org/datanucleus/store/rdbms/mapping/java/UUIDMapping.java#L141 getColumn() is assumed to be not null, but in 5.1.10 and higher it is. I have no idea what it would be null, but will try to dig in and compare to 5.1.9.
    Steve Springett
    @stevespringett
    This is all new code introduced in 5.1.10 which seems to be a regression of sorts
    Steve Springett
    @stevespringett
    FYI, I added a test case demonstrating the issue, and a PR to fix it.