3

I have some code where I have to be careful about how much ContentVersion data I load into memory at any particular time to avoid blowing the heap limit.

I was planning to do an initial query on ContentVersion.ContentSize to see how much I could load, and then use OFFSET and LIMIT to get the right amount each time.

But then I found that the query with LIMIT and OFFSET got surprising results. I boiled it down to this test, where I would expect all assertions to pass:

@IsTest
private class ContentVersionIsWeirdTest {

    @IsTest
    static void testBehavior() {
        List<ContentVersion> contentVersions = new List<ContentVersion> {
                new ContentVersion(VersionData = Blob.valueOf('One'), Title = 'One', PathOnClient = 'one'),
                new ContentVersion(VersionData = Blob.valueOf('Two'), Title = 'Two', PathOnClient = 'two')
        };
        
        insert contentVersions;

        Assert.areEqual(2, [SELECT Id FROM ContentVersion].size()); // PASS 
        Assert.areEqual(2, [SELECT Id FROM ContentVersion LIMIT 2].size()); // PASS
        Assert.areEqual(2, [SELECT Id FROM ContentVersion LIMIT 2 OFFSET 0].size()); // PASS
        Assert.areEqual(2, [SELECT Id, VersionData FROM ContentVersion].size()); // PASS
        Assert.areEqual(2, [SELECT Id, VersionData FROM ContentVersion LIMIT 2].size()); // PASS
        Assert.areEqual(2, [SELECT Id, VersionData FROM ContentVersion LIMIT 2 OFFSET 0].size()); // FAIL
    }
}

It seems like including VersionData makes the OFFSET 0 cause a problem. I can't see anything about this in the considerations for ContentVersion.

Is this a known thing that I've missed?

I do have a viable workaround - in the real code, I was always ordering by PathOnClient, and I know the files I want have unique paths, so I can use that to paginate through. But I'm curious about what's going on here.

0

You must log in to answer this question.

Browse other questions tagged .