I didn't "confirm" anything. I simply said maybe it wasn't completed.

Either way, in v6.0 that option is renamed "cascade-attach" since it provides for JPA CascadeType.MERGE (which is basically JDO "attach"). As a result "cascade-persist" will cater for both inserts and updates.

Hello,

I'm mapping a field using a AttributeConverter. The data stored is a string (json format).

AttributeConverter<xxx,byte[]>

Works great on MySQL. It's mapped on a medium blob.

AttributeConverter<xxx,String>

Works, only if the json is less than 255 characters.
So I tried to specify the column size using @Column(name= "metadatas",length = 2048) on the corresponding field, but schema is generated with varchar(255).
Am I doing something wrong ? Is this just not yet supported ?

For MySQL I would prefer to use the JSON data type. So I specified the type using @Column(name= "metadatas",columnDefinition = "JSON") on the field, but schema is still generated with varchar(255).
Am I doing something wrong ? Is this just not yet supported ?

Thanks for your help
--
Stephane

Correct (so then it would be consistent with the IS NULL block just above).
You find whether that has an effect by running the test suites under the "tests" repository, particularly those under "jpa". Unlikely to make a difference to existing cases

Hi, I believe I have found a bug in the JPQLParser class, but I'm not entirely sure.

Considering a User class, with a nullable 1-1 link to a UserAccount class, and a collection of Contract objects in the UserAccount class, and a JPQL query with the following form:

SELECT u FROM package.to.my.class.User u LEFT JOIN u.userAccount ua WHERE ua.contracts IS EMPTY

The code that parses the "IS EMPTY" clause is as follows (JPQLParser.processRelationalExpression()):

else if (lexer.parseStringIgnoreCase("EMPTY"))
{
    // Convert IS EMPTY to a method call of "size()==0" on collection/map
    Node sizeNode = new Node(NodeType.INVOKE, "size");
    inputNode.insertChildNode(sizeNode);
    Node isEmptyNode = new Node(NodeType.OPERATOR, not ? "!=" : "==");
    isEmptyNode.appendChildNode(inputNode);
    Node zeroNode = new Node(NodeType.LITERAL, 0);
    isEmptyNode.appendChildNode(zeroNode);
    stack.push(isEmptyNode);
}

Debugging through this code, I find that there is a variable "inputRootNode" which essentially contains ua.contracts, and the variable "inputNode" only contains the last part of this chain, in this case "contracts". However, in the else if statement to handle "EMPTY", the isEmptyNode appends inputNode as a child, instead of inputRootNode, which causes the node structure to end up like this:

[OPERATOR : ==.

    [IDENTIFIER : contracts.

        [INVOKE : size]],

    [LITERAL : 0]]

Notice how we lost the "ua." prefix for contracts. Then, at the end of the query compilation, we get a NucleusUserException, with the message "Class name contracts could not be resolved".

Replacing the line "isEmptyNode.appendChildNode(inputNode)" by "isEmptyNode.appendChildNode(inputRootNode)", similar to the previous if statement that handles the "NULL" case, seems to resolve the problem, but I'm not sure if that would have an impact on different queries or if there's more to it than that, but I thought I'd point it out. Maybe there is something wrong/not supported in the query I'm using?

Thanks Andy for the confirmation. Can we achieve the same the functionality through any other existing feature?

Maybe, since not a core JDO feature, nobody had time to implement it for 1-1 relations. Maybe there was no resource.

I have debugged and tried adding another field.
Class log
{
private int id;
@Persistent(column = "userId", defaultFetchGroup = "true")
@Extensions({@Extension(vendorName = "datanucleus", key = "cascade-update", value = "false")})
private User[] user;
}

Added user array instead of user. Now the casade-update seems to be working.
https://github.com/datanucleus/datanucleus-rdbms/blob/4.0/src/main/java/org/datanucleus/store/rdbms/mapping/java/ArrayMapping.java#L237
Any specific reason why it is not implemented for normal objects. Implemented for collections, maps and arrays only 

Class log
{
private int id;
@Persistent(column = "userId", defaultFetchGroup = "true")
@Extensions({@Extension(vendorName = "datanucleus", key = "cascade-update", value = "false")})
private User user;
}


Class User {
@Persistent(primaryKey = "true", valueStrategy = IdGeneratorStrategy.IDENTITY)
private int userId;
}

Every log has related user.

When updating or inserting log, we dont want to update user properties .
For example

Log log = new Log();
user.setRegion("CA")
log.set(user);

persist(log);

User region is getting updated even if cascade-update is false. [Cascade-persist is working!!]

Can some one please help on this ?

I debugged the code https://github.com/datanucleus/datanucleus-rdbms/blob/0812934216a04a63e953e173ebf4398250cc8150/src/main/java/org/datanucleus/store/rdbms/mapping/java/PersistableMapping.java#L598 cascade persist check is there but could not find any check for cascade-update. Should we persist data in different way ?

Hi Andy,

Pull Request created for this bug.
https://github.com/datanucleus/datanucleus-core/pull/406

It will be available in GitHub when I have time to translate what you have changed into something applyable. It won't be "released" until the next release, and since the last one was not long ago, that means at least 3 months.

Hi Andy,

Will this be available in 5.2.x release?

Hi Andy,

I don't have access to github.com. I have attached the files modified for this fix. Verified with our product it is working as expected.

Modified files in 5.2 branch
AbstractStoreManager.java
ValueGenerationManagerImpl.java

As i said, the JPA spec defines JPQL and it does NOT say that this query should work, nor does it use the term 'multi morph' anywhere.

DataNucleus allows JPQL to be used with JDO. But that query (candidate class using "subclass-table") is not supported like that, whether using JDOQL or JPQL. As also said, if you want that supported you need to contribute it

Hi, Andy,   it works in a lot of cases but not this case.  And it is mentioned in the document https://www.datanucleus.org/products/accessplatform_5_2/jdo/query.html#jpql.  as a datanucleus extension.

No, there is nothing in the JPA spec that says that.

If you want it then get the code and contribute it

HI, Andy,  for using jdo api to do jpaql,    we have legacy project which has a lot of jdoql and jpql at the same time. In the past, we used KODO+open jpa at the same time, Now, when we change to datanucleue,  we don't want to maintan persistanceManger and entityManager at the same time any more. But we still want to use the existing JPQLs.
 

Hi, Andy,  Thanks for answering.  What I expect is when I run "select t from izone.adams.model.messaging.SMSMessageAbstract t where t.creationDate>=:p_startDate ",  I should be able to get result without exception like  org.datanucleus.exceptions.NucleusUserException: Unable to find table for primary t.creationDate since the class izone.adams.model.messaging.SMSMessageAbstract is managed in multiple tables.  Look at the the exception, it concerns about how to handle multiple morph(return all kind of subclass object of SMSMessageAbstract ).

Right, so if that is important for you on 5.2 then please provide a Pull Request.

Define what you mean by "multi-morph feature of JPQL"? Provision of JPQL within JDO provides features that DataNucleus core/rdbms provide, just as JPQL within JPA/Jakarta.

I can't say I ever see a need to use JPQL when using JDO; JDOQL provides for that query.

We have :
public abstract class SMSMessageAbstract{
............
}