Hi fellow outsystemers,

I got a question regarding the entity tables. We want to store attachments to multiple entities, like entity X can have attachments, but so does entity Y and Z. 

Is it an idea to create this attachment-entity with a reference to the Entity.Id of the. table itself and a LongInteger representing the Id of the record within that entity? And if so, how do we get that Entity.Id??? Or is there a better solution to this problem??


Cheers!!

Hi,

On attachment entity create that attribute which is a long integer and represent the id in another entity. But you also need another attribute to state which entity that Id belongs too.

Regards,

Marcelo

Marcelo Ferreira wrote:

Hi,

On attachment entity create that attribute which is a long integer and represent the id in another entity. But you also need another attribute to state which entity that Id belongs too.

Regards,

Marcelo

awesome! But how can we state to which entity it belongs???


Hi! 

Why not use not use a static entity of your own to keep the entities that can have attachments? 

And then use the id of that static to identify the entity to which the document is attached to. 

Just a work around.

Regards

Graça

Hi Roemer,

Does it make sense to store all of those attachments inside the same Entity? Are they part of the same business concept, or are they only tangentially related?

I ask because I'd normally see a few Entities with clear, defined foreign keys instead of a Long Integer that must then be translated to the correct Entity. Depending on the number of Entities, I'd even consider a single Entity with multiple foreign keys to different Entities instead of a field that relies on too much logic to be translated into a usable row.

Afonso Carvalho wrote:

Hi Roemer,

Does it make sense to store all of those attachments inside the same Entity? Are they part of the same business concept, or are they only tangentially related?

I ask because I'd normally see a few Entities with clear, defined foreign keys instead of a Long Integer that must then be translated to the correct Entity. Depending on the number of Entities, I'd even consider a single Entity with multiple foreign keys to different Entities instead of a field that relies on too much logic to be translated into a usable row.

Hey Afonso,


The thing is we want to use this part of storage/functionality not for just one application / project. We want to build everything as reusable in multiple projects as possible! So we try to avoid any direct references to other entities in the form of ID's.


Hi Roemer,

not sure I understand your requirements, but if you feel like the storing and retrieving and maintaining of attachments should be a separate reusable component, would it not be an option to put the job of maintaining the relationship on the side of entityX, entityY etc.  So the attachment component needs no knowledge at all about the components it is used in ?

For example 

  • if entity X has only one attachment, it can have attachment identifier as an attribute
  • if entity Y has 2 distinct attachment with a different meaning, I'd add 2 attachment identifiers in it
    • for example, when an applicant needs to submit both an application form and a cv, i'd do something like
      • application
        • id
        • name
        • ApplicationForm  (= AttachmentId)
        • CV (= AttachmentId)
  • if entity Z can have zero, one or more attachment of a given type, you could add a relationship entity
    • for example, in a support system, if any number of screenprints or other documents can be attached to further document the issue being reported, then I'd do something like
      • Issue
        • id
        • description
        • ...
      • IssueAttachments
        • id
        • IssueId
        • AttachmentId


Dorine


Dorine Boudry wrote:

Hi Roemer,

not sure I understand your requirements, but if you feel like the storing and retrieving and maintaining of attachments should be a separate reusable component, would it not be an option to put the job of maintaining the relationship on the side of entityX, entityY etc.  So the attachment component needs no knowledge at all about the components it is used in ?

For example 

  • if entity X has only one attachment, it can have attachment identifier as an attribute
  • if entity Y has 2 distinct attachment with a different meaning, I'd add 2 attachment identifiers in it
    • for example, when an applicant needs to submit both an application form and a cv, i'd do something like
      • application
        • id
        • name
        • ApplicationForm  (= AttachmentId)
        • CV (= AttachmentId)
  • if entity Z can have zero, one or more attachment of a given type, you could add a relationship entity
    • for example, in a support system, if any number of screenprints or other documents can be attached to further document the issue being reported, then I'd do something like
      • Issue
        • id
        • description
        • ...
      • IssueAttachments
        • id
        • IssueId
        • AttachmentId


Dorine



Looks good! I will work this out! Thank you