Hi, When I update an attribute with the same value (let's say I replace with an equals value), this object is made dirty. Not a big deal, but a side effect is PreUpdate callbacks are triggered, and I

DataNucleus does standard multitenancy, as defined in the docs. A user is running the PMF/EMF and so on creation of a record the record is tagged against that user. Read is for data for that user ...

Hi, I'm looking again at how to segment data based on user "profile". An easy to understand concept is to imagine an organisation with subsidiaries, each having departments, departments organized in

Ah ok, thanks a lot. I have a script going from Kodo mapping to DN mapping. I could not map the "natural" keys until I tried "mapped-by", then DN was happy with the mapping. So that will not work and

The mapped-by refers to the FIELD in the other class that is an object of this objects type. Joining is on the PK of this class, always. There are no "special" field names. JDO does not support

Does mapped-by="id" have special semantics? Can a field that is not the primary key not be named "id"? If I have fields named "id" then mapped-by="id" will use the primary key instead of the field for

You're wrong in the mapping definition. @JoinTable has foreignKey and inverseForeignKey. Take it up with the people behind JPA why their definition of annotations are unintuitive ... but then you wont

Hi, I'm trying to specify foreign-key names. This helps to reduce the effort on db schema comparison at the end of development, to prepare the schema upgrade script. Actually it works very well on

I can't say there'll be an easy way of doing any of this. You have to create separate tables, hence table creation handling. You have to intercept inserts, updates, deletes hence persistence handling.

I would suspect non RDBMS would also be supportable. Concept being that each time an object is modified, the dirty fields of the given object (before and after) are persisted in a document/table,

thanks Andy, I probably mixed up the mapping... my bad... Why not the JDO, for many bad reasons... -- Stephane

Why not decide if you are using JDO mapping files or not? You seem to be trying to use JPA format for an attribute that is only defined for JDO. The doc doesn't make any mention of "default-value".

I would like to add the default value of a field to the database column definition, in order to have the SchemaTool generating it in the database. I tried like in the doc, but without

1). A CAST has syntax "(identifier)", as does your use of parentheses with a field (just like with Java). Hence the compiler would need to know all about candidate class, imports etc etc at the point

Hi again, 2 more things: 1) Parser Bug I think I found a bug in the JDOQL query parser: booleans fields in parentheses lead to javax.jdo.JDOUserException: Method/Identifier expected While these are ok

Sure it's an amazing amount of good quality work you did those past 17 years ! Here I don't know how to make a test case. It's linked to the database settings at the schema creation time, and how they

DN applies whatever it is told to use by the user, such as via "datanucleus.identifier.case", as defined in the docs. I've never had a need for changing the code to use MariaDB, so have to assume that

Hi, I'm facing some issue to use a fresh new mysql8 server. DN doesn't find the tables because of case sensitivity. Tables are created in lowercase while DN search for upper case. Debugging schema

Neither JDO nor JPA provide any standardised "auditing" capability. DataNucleus provides first level support for auditing only, namely the ability to tag the create / update user/timestamp against

I'm evaluating DataNucleus as a JDO implementation vs a Hibernate JPA implementation. On of the big selling points that Hibernate provides is the Hibernate-Envers (https://hibernate.org/orm/envers/)