Skip to Content (Press Enter)
2017-11-14 19-03-39
Roemer Cleveringa
260Views
7Comments
Get the System Entity Id
Question

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!!

1
0
02 Sep 2019
Copy Link
2019-05-22 11-30-09
Marcelo Ferreira

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

0
0
02 Sep 2019
Copy Link
2017-11-14 19-03-39
Roemer Cleveringa

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???


0
0
02 Sep 2019
Copy Link
2018-06-05 16-54-03
Maria da Graça Peixoto

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

0
0
02 Sep 2019
Copy Link
2019-06-15 21-39-22
Afonso Carvalho
 
MVP

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.

1
0
02 Sep 2019
Copy Link
2017-11-14 19-03-39
Roemer Cleveringa

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.


1
0
09 Sep 2019
Copy Link
2021-09-06 15-09-53
Dorine Boudry
 
MVP

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


2
0
09 Sep 2019
Copy Link
2017-11-14 19-03-39
Roemer Cleveringa

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

0
0
10 Sep 2019
Copy Link
Community GuidelinesBe kind and respectful, give credit to the original source of content, and search for duplicates before posting.