The schedule's class 'todayDate' variable isn't visible in the batch class' scope, so when you pass a string query to the other class, it doesn't have anything to bind to when it eventually gets to executing the query. Therefore, when the system tries to perform the query in the start method, it doesn't find the variable todayDate and assigns a value of null to it.
In general, it's a bad idea to have one class give another class queries; the batchable class should be responsible for generating the query, which generally avoids scoping issues and makes it more obvious as to what data is being queried. The exception to this rule are those batchable classes that are polymorphic, such as a generic data processing class (e.g. a data loader, etc).
At minimum, you should assign the date value to the batchable class directly. Ideally, you shouldn't construct a query outside the class, because this means that the batchable class becomes dependent upon another outside class.
On the other hand, you can implement batchable and schedulable in the same class, which avoids the issue entirely:
public class X implements Database.Batchable<SObject>, Schedulable {
public void execute(SchedulableContext sc) {
// Do initial setup
Database.executeBatch(this, scopeSize);
}
public Database.QueryLocator start(Database.BatchableContext bc) {
return Database.getQueryLocator(query);
}
public void execute(Database.BatchableContext bc) {
// process
}
public void finish(Database.BatchableContext bc) {
}
}
Using this design, you can make todayDate a class variable and share its scope across the schedulable and batchable states.
The only value that gets updated in the Apex instance for any SObject when you insert is the Id value. Other fields populated as part of the insert by triggers or other logic have to be re-queried to get the values - ContentVersion is no different.
Quite a lot can go on behind the scenes for ContentVersion, including the automatic addition of a ContentDocumentLink to the User who inserted the version.
I've found ContentNote/ContentDocument/ContentVersion/ContentDocumentLink quite awkward to work with compared to e.g. just a Note.
Best Answer
You have to execute a query to retrieve any fields that are populated automatically when you perform DML, except
Id.Idis the only field the system will automatically populate in your sObjects when you perform an insert.Here, you must do