Announcement Announcement Module
No announcement yet.
Relations and performance Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • Relations and performance

    How to solve following situation:

    PHP Code:
    entity --class ~.ImageWrapper
    field string 
    --fieldName url --notNull
    --class ~.Album
    field set 
    --fieldName images --type ~.ImageWrapper 
    This way the "Create Album" form has a Listbox containing every single ImageWrapper entry. So each time I create a new Album instance, I have to read all images from the database.

    If I used a reference to Album in the ImageWrapper class instead, I'd end up with a listbox containing all Albums in the "Create Thumbnail" form.

    This approach does not work with a lot of data.

    So what is the most elegant way to model this?

  • #2
    All entities have a findXEntries method which allows for pagination, so you probably want to use this instead. You can also use Roo's dynamic finders if you know which items you want to display. To use them, you need to push in the relevant methods in your controllers (marked with @ModelAttribute).


    • #3
      This won't work for scaffolded code

      Thanks for your response Stefan. I know, that I can use the findXEntries, paging or dynamic finders for my custom code. However the scaffolded controllers will contain queries to all entities of the referenced type to populate their create/update forms, right? In my example that would be a call to findAllImageWrappers each time I create a new Album or edit an existing one.

      There are only two unsatisfying workarounds I came up with:

      1) Don't use references in the entity model
      2) Rewrite the scaffolded code for create/update operations to query referenced entities lazily

      Is there any best-practice or better way to avoid this problem, so that I can use the roo-generated code even if I have a large dataset?
      Last edited by Torquester; Jul 25th, 2011, 05:09 AM.


      • #4
        We are aware that things are not optimal with the use of @ModelAttributes. We are planning to address this issue for the next release. Feel free to comment on the existing ticket for this: for suggestions.