2

I am using ISIS 1.16.2 for a project at work and struggling with attachments and some related issues. I hope, you can help me (at least for a subset of my issues).

Context: My item classes need to store an arbitrary number of attachments (Blobs and/or Clobs).

From the example for one attachment:

@Persistent(defaultFetchGroup = "false",
    columns = { @Column(name = "attachment_name"),
                @Column(name = "attachment_mimetype"),
                @Column(name = "attachment_bytes",
                    jdbcType = "BLOB",
                     sqlType = "LONGVARBINARY")
    })
@Column(allowsNull = "true")
private Blob attachment;

First approach for multiple attachments:

@javax.jdo.annotations.Persistent(???)
@org.apache.isis.applib.annotation.Property(
        domainEvent = AttachmentDomainEvent.class,
        optionality = Optionality.OPTIONAL,
        hidden = Where.ALL_TABLES)
@org.apache.isis.applib.annotation.Collection
@lombok.Getter
private List<Blob> attachments = new LinkedList<>();
  1. Question: How do I have to annotate this field so that the elements of this list are stored in a self-contained table instead of being serialized into a single column of the containing object? Unfortunately I am not yet familiar with these annotations for nested types.
  2. Question: Can ISIS handle multiple file uploads simultaneously? For example as an action: @Action public void uploadFiles(List<Blob> files) {...}
  3. Question: Is it possible with ISIS 1.16.2 (or future versions) to store some meta information with the Blob/Clob entries (for example size, owner etc.) in a dedicated table without loosing the capability of ISIS/Wicket to show a download button, a preview etc. for a custom extended BLOB class?

Maybe a bit off-topic but related to the problem above:

  1. Question: With the collection property List<Blob> attachments; (see above), I get ??? EntityModel objectAdapter oid: null for each attachment in the table because the Blob/Clob classes are value types instead of reference types. What is the "right" way to provide the necessary information to render these value types correctly? (I have the same issue with enum sets)

Thanks in advance!

JND
  • 65
  • 7
  • To persist a Collection of a non Persistable type into a join table you need to add `@Join`, as per basic JDO docs http://www.datanucleus.org:15080/products/accessplatform_5_2/jdo/mapping.html#one_many_nonpc_join –  Jan 30 '19 at 18:08

1 Answers1

1

Ans 1: It isn't possible to store a List<Blob> as a single property. Instead, you'll need to define an entity, call it something like Document, and let it have a single Blob. You can then have a List<Document>. That might seem like more work (it is, I suppose), but you'll probably have some metadata that you want to store about those Blobs anyway. In effect, the Blob becomes an entity rather than a value.

Ans 2: not supported, see previous answer.

Ans 3: no, it doesn't. I think it would be possible to implement something like this (I see that Wicket 7 has a widget [1] to support it), so raise a ticket on the Apache Isis JIRA.

Ans 4: this is what an entity such as Document (as per ans. 1) would let you do. You can still provide a download action, this would be a regular action on the Document... just return the Blob as the return type of the action and it'll be downloaded. Also, if by any chance these blobs you are storing are PDFs, then check out the pdfjs viewer [2] from the incode platform.

Dan Haywood
  • 2,215
  • 2
  • 17
  • 23
  • Thank you for your quick and detailed reply! I will try this on monday at work. – JND Feb 01 '19 at 08:50
  • 1
    A little supplement to this answer: I introduced a `Document` class as proposed by Dan with additional meta data and a preview for PDFs (with _pdfjs_), plain text, HTML files and a text renderer for viewing the file tree of a ZIP archive (each using Markup and HTML+CSS styling). This solved problems 1, 3 and 4. For question 2 I implemented a kind of workaround: users can upload a zipped archive and the service unzips the documents. – JND Mar 27 '19 at 12:41
  • Thanks for posting this update. That sounds like a rather useful implementation of Document. Any chance you could share it in some form for others to leverage? – Dan Haywood Mar 29 '19 at 08:57