Announcement Announcement Module
Collapse
No announcement yet.
Generated Scaffold Delete functionality not working... Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Generated Scaffold Delete functionality not working...

    I've used roo's "controller scaffold" command to generate the CRUD views for my application. (Tried with both RC2 and RC3)

    These generated actions work perfectly well: create, list, show, edit and all of my findBy's; however, when I click the 'Delete' icon from the list view, nothing deletes and the Console shows:

    Processing injected field of bean 'com.qualcomm.idm.domain.Pim': PersistenceElement for public transient javax.persistence.EntityManager com.qualcomm.idm.domain.Pim.ajc$interField$com_qua lcomm_idm_domain$entityManager
    Returning cached instance of singleton bean 'entityManagerFactory'
    result row: EntityKey[com.qualcomm.idm.domain.Pim#50675]
    Processing injected field of bean 'com.qualcomm.idm.domain.Pim': PersistenceElement for public transient javax.persistence.EntityManager com.qualcomm.idm.domain.Pim.ajc$interField$com_qua lcomm_idm_domain$entityManager
    Returning cached instance of singleton bean 'entityManagerFactory'
    result row: EntityKey[com.qualcomm.idm.domain.Pim#50676]
    ... (repeats for what appears to be each entity)
    resolving associations for [com.qualcomm.idm.domain.Pim#81990]
    done materializing entity [com.qualcomm.idm.domain.Pim#81990]
    initializing non-lazy collections
    aggressively releasing JDBC connection
    Rendering view [org.springframework.web.servlet.view.tiles2.TilesV iew: name 'pim/list'; URL [pim/list]] in DispatcherServlet with name 'idMapper'
    Added model object 'pims' of type [java.util.ArrayList] to request in view with name 'pim/list'
    Render request recieved for definition 'pim/list'
    Nov 12, 2009 11:20:00 AM org.apache.catalina.core.ApplicationDispatcher invoke
    SEVERE: Servlet.service() for servlet jsp threw exception
    java.lang.OutOfMemoryError: Java heap space

    The legacy table that it is going against didn't have a version field so I tried configuring it to use an @Transient version field. When that didn't work I tried actually adding a version field to the table and that still didn't help.

    Any idea why the Delete action isn't working?

    NOTE: Someone might want to fix the spelling of "Render request recieved"

  • #2
    I'll leave Stefan to comment on why the delete isn't working, but the misspelling of "render request recieved" is within the Tiles source code, not Roo or Spring: http://www.docjar.com/html/api/org/a...iner.java.html

    Re your delete problem, which JPA provider are you using? Have you tried it with Hibernate?

    Comment


    • #3
      Unfortunately, it is impossible to determine what went wrong from the exception stack trace you have posted here. Is it possible that you are trying to delete an Entity that is currently referenced by another? In that case I would expect for you to see a reference integrity violation exception or something similar.

      For example, in the petclinic sample I can create and delete pet types successfully until I actually create a pet which references a pet type. In that case I can only delete pet types once I have deleted all pets that reference that pet type. The ORM takes care of checking such integrity violations and therefore will not permit deletion of pet types that are referenced. This behaviour can be adjusted by using cascade annotation attributes in JPA.

      If you can confirm that this is not the case and the entity should really have been deleted (no constraints in place which should logically prevent the deletion) you should open a bug ticket in our Jira. Please attach the complete script to replicate the application, information about your environment, and (possibly) even the application sources themselves.

      Cheers,
      Stefan

      Comment


      • #4
        Still cannot get Delete functionality to work

        This should be a really simple case since there are no dependencies on the table. The only custom part is that I modify the Entity after creation so that the id is generated using a sequence. The create functionality is fine... It's just the Delete that blows up.

        The Oracle 10g database table has the following structure:
        Describing PERSON_ID_MAPPER....
        ------------------------------- --------- -----
        ID_PK.........................NOT NULL NUMBER(10,0)
        QCGUID........................NOT NULL NUMBER(10,0)
        EMP_NUM.......................NUMBER(10,0)
        NEW_HIRE_ID..................NUMBER(10,0)
        CANDIDATE_ID................NUMBER(10,0)
        ALIAS_NAME.................VARCHAR2(50)
        CREATED......................DATE
        LAST_UPDATED.............DATE
        VERSION......................NUMBER(10,0)


        The app that I'm trying to generate is created from the following script:

        project --projectName idMapper --topLevelPackage com.qualcomm.idm

        persistence setup --provider HIBERNATE --database ORACLE

        entity --name ~.domain.Pim --table person_id_mapper --identifierField id --identifierColumn id_pk --testAutomatically

        field number --class ~.domain.Pim --fieldName qcguid --type java.lang.Integer --column qcguid --notNull --min 0

        field number --class ~.domain.Pim --fieldName empNum --type java.lang.Integer --column emp_num --min 0
        field number --class ~.domain.Pim --fieldName newhireId --type java.lang.Integer --column new_hire_id --min 0
        field number --class ~.domain.Pim --fieldName candidateId --type java.lang.Integer --column candidate_id --min 0
        field string --class ~.domain.Pim --fieldName alias --column alias_name

        field date --class ~.domain.Pim --fieldName created --type java.util.Date --column created
        field date --class ~.domain.Pim --fieldName lastUpdated --type java.util.Date --column last_updated


        Modified Pim.java Entity:
        package com.qualcomm.idm.domain;

        import ...

        @Entity
        @RooJavaBean
        @RooToString
        @Table(name = "person_id_mapper")
        @SequenceGenerator(name = "IdSeq", sequenceName = "person_id_mapper_pk_seq")
        @RooEntity(finders = {
        "findPimsByQcguid", "findPimsByEmpNum", "findPimsByNewhireId",
        "findPimsByCandidateId", "findPimsByAlias",
        "findPimsByEmpNumOrNewhireIdOrCandidateId" })
        public class Pim {

        @Id
        @GeneratedValue(strategy = GenerationType.SEQUENCE, generator = "IdSeq")
        @Column(name = "id_pk")
        protected Long id;

        public Long getId() {
        return id;
        }

        public void setId(Long id) {
        this.id = id;
        }
        ...
        }


        I've tried recreating from scratch and still cannot delete a record. When I click the 'Delete' icon, the Console shows that it is iterating over what appears to be ALL of the records... [see previous post] until it eventually throws an 'OutOfMemoryError: Java heap space'. I added a System.out.println() to the PimController.delete() method in the PimController_Roo_Controller.aj file, but it never appears in the Console so I assume that it was never even called.

        Please advise...

        Comment


        • #5
          As I don't have a Oracle install handy this will be hard to test. Can you do the opposite and create a project with the default key strategy that Roo uses and the HYPERSONIC_IN_MEMORY database. Just so you can confirm that the delete works there with an otherwise similar setting. Also, as mentioned before, we need to see the complete stack trace to determine the root cause of this issue.

          The configuration you are showing looks ok, but I am not a JPA expert when it comes to using sequence generators. I wonder if this is more of a JPA implementation issue. Have you tried swapping Hibernate for OpenJPA?

          -Stefan

          Comment


          • #6
            Everything works fine using the in-memory database.
            Even if the delete functionality did work if I don't use the sequence, I need to use it so...
            All of my applications are already using Hibernate so I don't really want to change.

            I've attached the stack trace that the Roo app displays. I can't seem to find the application.log file that the app should be creating either. Where should that file be? I'm running as an app on a Tomcat 6.0 server.

            Is there anyone who can look at this?

            Comment


            • #7
              It looks like the "root cause" part of the exception stack trace attachment is missing. We'd like to see if possible the root cause, as it helps us understand it more fully. Can you also please post (removing passwords and host names etc) your database.properties and persistence.xml so we can attempt to reproduce your configuration. Also it's probably worth using "persistence setup --provider OPENJPA --database ORACLE" and re-running your tests. You can easily go back to Hibernate with "persistence setup --provider HIBERNATE --database ORACLE". It could well be the JPA implementation, especially given it's working OK with an in-memory database. Also the exception message is indicating the exception is emerging from Hibernate classes themselves, further suggesting it's either configuration or Hibernate (but if you could try the above suggestions and provide a full stack trace it would help us greatly work through this problem with you).

              Comment


              • #8
                How can I provide the full stack trace if I can't file the application.log file? I just attached a .zip that has the full console output.

                I switched it to OpenJPA and again, everything lists, adds, shows and edits just fine. When I click the Delete icon, the app crashes with the attached information from the console. NOTE: When I restart the app the record that I chose to delete has been deleted.
                Code:
                database.properties
                
                database.password=*******
                database.url=jdbc\:oracle\:thin\:@****dev01\:1528\:IVQCDEV
                database.username=iv_user
                database.driverClassName=oracle.jdbc.OracleDriver
                Code:
                persistence.xml
                
                <?xml version="1.0" encoding="UTF-8" standalone="no"?>
                <persistence xmlns="http://java.sun.com/xml/ns/persistence" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" version="1.0" xsi:schemaLocation="http://java.sun.com/xml/ns/persistence http://java.sun.com/xml/ns/persistence/persistence_1_0.xsd">
                
                    <persistence-unit name="persistenceUnit" transaction-type="RESOURCE_LOCAL">
                        <provider>org.apache.openjpa.persistence.PersistenceProviderImpl</provider>
                        <properties>
                            <property name="openjpa.jdbc.DBDictionary" value="org.apache.openjpa.jdbc.sql.OracleDictionary"/>
                            <property name="openjpa.jdbc.SynchronizeMappings" value="buildSchema"/>
                        </properties>
                    </persistence-unit>
                </persistence>
                Last edited by qualcommLisa; Nov 20th, 2009, 02:47 PM. Reason: Adding requested information.

                Comment


                • #9
                  Deleting a record isn't the problem...

                  I finally found the source of the problem... but I'm still not sure of the best solution.

                  The record is indeed deleted. However, the app then redirects to pim/list without passing any size or page info. My table has over 50k records so it is running out of Java Heap space when it tries to render the table! For now I just modified PimController.delete() to accept the ModelMap parameter and then I added the size attribute with a default value of (int) 10 to it and all is well.

                  Should this be added as a Jira ticket? It seems to me that if it's going to redirect to the list after deleting a record then it should have a notion of the size and page params.
                  Last edited by qualcommLisa; Nov 20th, 2009, 04:00 PM.

                  Comment


                  • #10
                    I definitely agree the "list" use case should have a suitable self-defence mechanism in it. Would you please log this as a "bug" (even though it's really an "enhancement" but it will get higher visibility/priority as a bug and you can say to Stefan I said it was a "bug" when he points out it's an "enhancement" ;-) ) at https://jira.springsource.org/browse/ROO. My first-stab suggestion would be the list use case just defaults to getting records 1 to 100 if there's no explicit range required in the URI. Nice, transparent, safe. But Stefan might have a better model, as he's more familiar with the web use cases and add-ons than I am.

                    Comment


                    • #11
                      As Ben predicted I have marked this ticket as improvement rather than bug since nothing was broken beforehand really.

                      Nonetheless, revsion 493 in Roo trunk provides a solution to your problem. Effectively the delete method exposed by the controller is now aware of the page and size parameters. If these values are not passed in as part of the URI (or as a hidden parameter) the controller will set these parameters automatically to page=1 and size=10 so it is in line with the other default values.

                      Hope this helps. It would be great if you could test this from Roo trunk. Roo RC4 will ship this improvement (not a bug since nothing was broken previously).

                      -Stefan

                      Comment

                      Working...
                      X