Class "com.jofrantoba.indiant.server.model.beans.Interest" field "version": defined in the MetaData, but this field does not exist in the class!
DataNucleus Enhancer terminated with an error. Please read the LOG for details. There were errors with some of the classes
DataNucleus Enhancer terminated with an error. Please read the LOG for details. There were errors with some of the classes
The field is in the parent class of interest
@Embedded(nullIndicatorColumn="interest", members={
@Persistent(name="description", columns=@Column(name="description")),
@Persistent(name="GlobalEntityPkLong.version", columns=@Column(name="version"))
})
@Persistent
private Interest interest;
@Persistent(name="description", columns=@Column(name="description")),
@Persistent(name="GlobalEntityPkLong.version", columns=@Column(name="version"))
})
@Persistent
private Interest interest;
GlobalEntityPkLong.version
this is working
I want to rename the fields
el id y la descripcion es lo que necesito, lo otros campos no quiero que se guarden
This code gives me this result. It's how I wanted it
but i am wondering if there is way to skip these two fields:
interest_version and interest_isPersistent
interest_version and interest_isPersistent
As per the JDO spec, specifying a field metadata within an "embedded" declaration defines the metadata for that embedded field. Just cos you didn't specify some doesn't mean they aren't persisted. aka "it works as expected". The only way an embedded field could "potentially" not be persisted is by specifying '@NotPersistent' but then whether that is supported in the datastore plugin is undefined
This is my environment
I am testing the test with the current libs to see if everything is fine
I am getting these errors
@jofrantoba If you get compilation errors, how would you normally resolve them? Because datanucleus-api-jdo clearly has those methods https://github.com/datanucleus/datanucleus-api-jdo/blob/master/src/main/java/org/datanucleus/api/jdo/annotations/SoftDelete.java
Is it necessary to clean in each test?
if not clean I get this
----------< com.jofrantoba.indiant:indiant-daos-datanucleus >-----------
Building indiant-daos-datanucleus 1.0.0
--------------------------------[ jar ]---------------------------------
--- datanucleus-maven-plugin:5.2.1:test-enhance (default-cli) @ indiant-daos-datanucleus ---
Writing fileListFile: C:\Users\jona\AppData\Local\Temp\enhancer-771217791195794323.flf
Standard error from the DataNucleus tool + org.datanucleus.enhancer.DataNucleusEnhancer :
La l¡nea de comandos es demasiado larga.
--------------------
BUILD FAILURE
Total time: 2.111 s
Finished at: 2021-11-22T11:14:28-05:00
Failed to execute goal org.datanucleus:datanucleus-maven-plugin:5.2.1:test-enhance (default-cli) on project indiant-daos-datanucleus: The DataNucleus tool org.datanucleus.enhancer.DataNucleusEnhancer exited with a non-null exit code. -> [Help 1]
To see the full stack trace of the errors, re-run Maven with the -e switch.
Re-run Maven using the -X switch to enable full debug logging.
For more information about the errors and possible solutions, please read the following articles:
[Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
@jofrantoba I dont see what DataNucleus has to do with that. A test, at runtime, needs to have classes that are compiled+enhanced. How you get your environment to provide that is for you to decide. If a class is already enhanced and you try to enhance again, the enhancer will simply do nothing. There is no error shown there that is a DataNucleus problem. "La linea de comandos es demasiado largo" ... and that comes from where? your environment? Start by working out what command it is trying to invoke
Hi, would like to know if this warning is still valid?
@raymondnathan__twitter Firstly please just post actual text rather than tiny images that have to be zoomed in to read. Secondly just because there is an API method (interface) doesnt mean it is supported. Method invocation for MongoDB is shown clearly enough in https://github.com/datanucleus/datanucleus-mongodb/blob/master/src/main/java/org/datanucleus/store/mongodb/query/QueryToMongoDBMapper.java#L746 and there is no explicit support for equalsIgnoreCase, and that is why you get that message (so how "it works" is undefined). If you have support to contribute for that method then you know how to do that. Thx
Hi, is there any chance that views and/or partitioned tables will be supported in DataNucleus/JDO? Currently I replaced an existing PostgreSQL table that became 43GB into a partitioned one but now DN complains about it like
Table "isodbmap_master" is of wrong type PARTITIONED TABLE. Should be a table. Same for the view on it.
@Jeaninev RDBMS tables currently uses "TABLE" or "BASE TABLE", and views use "VIEW" as the supported types. See https://github.com/datanucleus/datanucleus-rdbms/blob/master/src/main/java/org/datanucleus/store/rdbms/table/TableImpl.java#L165 and https://github.com/datanucleus/datanucleus-rdbms/blob/master/src/main/java/org/datanucleus/store/rdbms/table/ViewImpl.java#L104 . Clearly every RDBMS does random stuff and includes their own types in that text field - failure of the JDBC spec to define them. You can easily get the code and extend it, and contribute it back with specific info about WHICH RDBMS does this
The names referred to are what DatabaseMetaData.getTableTypes() returns. https://docs.oracle.com/en/java/javase/11/docs/api/java.sql/java/sql/DatabaseMetaData.html#getTableTypes()
Hello!
One the field in my data model is of type CLOB: I noticed that even if I add this field in a fetch group to eagerly fetch it, it doesn't work. That is, an additional query is issued to the DB to fetch the CLOB field. Do you have any idea how I can avoid this additional query? Thanks!
One the field in my data model is of type CLOB: I noticed that even if I add this field in a fetch group to eagerly fetch it, it doesn't work. That is, an additional query is issued to the DB to fetch the CLOB field. Do you have any idea how I can avoid this additional query? Thanks!
5 replies