Querying ContentDocumentLink Objects.

Using Version django-salesforce 4.0.

I have the following model:

class ContentDocumentLink(models.Model):
    linkedentityid = models.CharField(db_column='LinkedEntityId', max_length=18)
    contentdocumentid = models.CharField(db_column='ContentDocumentId', max_length=18)
    isdeleted = models.BooleanField(db_column='IsDeleted')
    systemmodstamp = models.DateTimeField(db_column='SystemModstamp')
    sharetype = models.CharField(db_column='ShareType', max_length=40, blank=True, null=True)
    visibility = models.CharField(db_column='Visibility', max_length=40, blank=True, null=True)

    class Meta:
        managed = False
        db_table = 'ContentDocumentLink'

Do to some limitation on salesforce we cannot do:

ContentDocumentLink.objects.all()

because it generates the query:

SELECT ContentDocumentLink.Id, ContentDocumentLink.LinkedEntityId,
    ContentDocumentLink.ContentDocumentId, ContentDocumentLink.IsDeleted,
    ContentDocumentLink.SystemModstamp, ContentDocumentLink.ShareType, ContentDocumentLink.Visibility
FROM ContentDocumentLink

that will throw the error:

MALFORMED_QUERY: Implementation restriction: ContentDocumentLink requires a filter
    by a single Id on ContentDocumentId or LinkedEntityId using the equals operator
    or multiple Id's using the IN operator.

When I try to do:

ContentDocumentLink.objects.filter(contentdocumentid__in=['0693X00000IJWDNQA5', '0693X00000IJWDOQA5']).

the generated query:

SELECT ContentDocumentLink.Id, ContentDocumentLink.LinkedEntityId,
    ContentDocumentLink.ContentDocumentId, ContentDocumentLink.IsDeleted,
    ContentDocumentLink.SystemModstamp, ContentDocumentLink.ShareType, ContentDocumentLink.Visibility
FROM ContentDocumentLink
WHERE
    ContentDocumentLink.ContentDocumentId IN ('0693X00000IJWDNQA5', '0693X00000IJWDOQA5')

throws the same error because salesforce does not recognise “ContentDocumentLink.ContentDocumentId” as being the same as “ContentDocumentId”, i.e., one of the mandatory fields.

I’ve been able to execute the following raw query without problems:

ContentDocumentLink.objects.raw(
    """SELECT ContentDocumentLink.Id, ContentDocumentLink.LinkedEntityId, ContentDocumentLink.ContentDocumentId,
ContentDocumentLink.IsDeleted, ContentDocumentLink.SystemModstamp, ContentDocumentLink.ShareType,
ContentDocumentLink.Visibility
FROM ContentDocumentLink WHERE ContentDocumentId IN ('0693X00000IJWDNQA5', '0693X00000IJWDOQA5')""")

My conclusion is that salesforce assumes that the ContentDocumentId (or LinkedEntityId) must be present on the where part of the query but does not accept ContentDocumentLink.ContentDocumentId.

Is it possible to force the django generated sql queries to drop all the explicit table names of the fields? Maybe only on the where part of the queries? Is there a better solution?

[hynekcer]

A good message is that a non-intuitive arrangement with .sf(minimal_aliases=True) will be not necessary soon because this bug is restricted only to the following well known five objects.

['ContentDocumentLink', 'ContentFolderItem', 'ContentFolderMember', 'IdeaComment', 'Vote']

This list can be added to django-salesforce source. A selective automatic use of minimal_aliases prevents a risk that a quality of some complicated queries on normal tables could be degraded by general use of minimal_aliases.

If any new object with Implementation restriction: *** requires a filter by will be added in a future Salesforce version then it can be detected automatically by tests/inspectdb/test.sh in Salesforce sandbox preview period. A patch version with that new name could be released. It is probable, that when a developer starts to use a very new object then he/she can also start to use a new django-salesforce version. Many objects with such restriction when they were new are now without a restriction. It is easier for Salesforce to remove later an unnecessary restriction than to must add an underestimated restriction to an existing object type.

[philchristensen]

I’m going to suggest we time box this for another week or so. If @gredondogc can provide some test data by, say, March 26th or so, we’ll include it in the release. Otherwise we’ll drop 4.0.1 around April 1st as-is.

@hynekcer sound good to you?