Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Jonathan Franchesco Torres Baca
    @jofrantoba
    image.png
    Jonathan Franchesco Torres Baca
    @jofrantoba
    How can I access the parent class field from the Embedded tag?
    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
    The field is in the parent class of interest
    Andy Jefferson
    @andyjefferson
    Any field in a persistent class is visible. Yours is not and we dont see the class(es)
    Jonathan Franchesco Torres Baca
    @jofrantoba
    @Embedded(nullIndicatorColumn="interest", members={
    @Persistent(name="description", columns=@Column(name="description")),
    @Persistent(name="GlobalEntityPkLong.version", columns=@Column(name="version"))
    })
    @Persistent
    private Interest interest;
    GlobalEntityPkLong.version
    this is working
    image.png
    I want to rename the fields
    image.png
    el id y la descripcion es lo que necesito, lo otros campos no quiero que se guarden
    Jonathan Franchesco Torres Baca
    @jofrantoba
    the id and the description is what I need, the other fields I do not want to be saved
    Jonathan Franchesco Torres Baca
    @jofrantoba
    is there a way that it does not take the fields that I mark through annotations?
    Jonathan Franchesco Torres Baca
    @jofrantoba
    image.png
    This code gives me this result. It's how I wanted it
    image.png
    but i am wondering if there is way to skip these two fields:
    interest_version and interest_isPersistent
    Jonathan Franchesco Torres Baca
    @jofrantoba
    members of embedded tag I think it is not working as expected, or only serves to rename
    Andy Jefferson
    @andyjefferson
    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
    Jonathan Franchesco Torres Baca
    @jofrantoba
    @andyjefferson
    image.png
    This is my environment
    image.png
    I am testing the test with the current libs to see if everything is fine
    I am getting these errors
    image.png
    Andy Jefferson
    @andyjefferson
    @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
    Jonathan Franchesco Torres Baca
    @jofrantoba
    Hi, @andyjefferson
    Jonathan Franchesco Torres Baca
    @jofrantoba
    I am using datanucleus JDO with maven and in each execution and test it is mandatory to execute a clean and enhancer for each execution.
    Can I have a more optimal configuration?
    Andy Jefferson
    @andyjefferson
    @jofrantoba Any test needs enhanced classes. DN test suite enhaces classes post compile and then runs all tests; that is optimal. You dont say what tests you're talking about.
    Jonathan Franchesco Torres Baca
    @jofrantoba
    image.png
    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

    Andy Jefferson
    @andyjefferson
    @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
    Raymond Nathan
    @raymondnathan__twitter
    image.png
    Hi, would like to know if this warning is still valid?
    Andy Jefferson
    @andyjefferson
    @raymondnathan__twitter since you got the message, then it clearly is.
    Raymond Nathan
    @raymondnathan__twitter
    Based on the message, it should mean all method invocation which in this case is the equalsIgnoreCase should not work, but in my test it works fine. Is there something I am misunderstanding.
    Andy Jefferson
    @andyjefferson
    The message says equalsIgnoreCase is not supported. And there is no code in GitHub to support it.
    Raymond Nathan
    @raymondnathan__twitter
    I don't understand, isn't the equalsIgnoreCase a part of the data nucleus javax.jdo.query package (3.2.0-release). It is working in my repository impl.
    image.png
    Andy Jefferson
    @andyjefferson
    @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
    Jeanine
    @Jeaninev
    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.
    Andy Jefferson
    @andyjefferson
    @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
    Andy Jefferson
    @andyjefferson
    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()
    nsanglar
    @nsanglar
    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!
    Andy Jefferson
    @andyjefferson
    @nsanglar You look in the log at what is happening, and debug your code and fetch groups. Works for me
    nsanglar
    @nsanglar
    @andyjefferson Thanks for your answer, you mean that in your case CLOB fields are fetched eagerly?
    5 replies