You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
All versions of SilverStripe (up to 4.4.4 at time of writing).
Description
Currently we have two methods that do almost exactly the same thing (both semantically and functionally). My opinion is currently that we should either:
Simply point ->exists() to ->isInDB() since, at the DataObject level, it exists if it is also in the DB. For files, this degree of differentiation may make sense because the file can potentially still be in the database but no longer "exist" on the file system (or on some object store) or vice versa.
Deprecate (and ultimately remove) ->isInDB() since it is redundant at the DataObject level (as it can only exist in the database). This of course discards the notion of "existing" as an ephemeral object in memory which hasn't yet had a ->write() call, of course (since that is implicit). If this is done, it should just be added on classes lower down where it makes sense to differentiate between the two.
IMHO, the method ->exists() should be a canonical method of determining that an object is properly present in all it's necessary forms. For example, with simple data this method will ensure it's in the database (regardless of how that is actually determined, e.g. simple ID check or actually hitting the DB with a query to verify). For files, this should also presumably look at storage to validate existence.
Also, another argument for this is that these two methods (at least in DataObject) are nearly identical:
I'd like to hash this out since I want to standardize my code on a method like ->exists() instead of doing a direct check of $obj->ID > 0 since that would likely be impacted if we ever moved to a UUID-based ID system like those discussed or proposed in #6819 and #8411.
Affected Version
All versions of SilverStripe (up to 4.4.4 at time of writing).
Description
Currently we have two methods that do almost exactly the same thing (both semantically and functionally). My opinion is currently that we should either:
->exists()
to->isInDB()
since, at theDataObject
level, it exists if it is also in the DB. For files, this degree of differentiation may make sense because the file can potentially still be in the database but no longer "exist" on the file system (or on some object store) or vice versa.->isInDB()
since it is redundant at theDataObject
level (as it can only exist in the database). This of course discards the notion of "existing" as an ephemeral object in memory which hasn't yet had a->write()
call, of course (since that is implicit). If this is done, it should just be added on classes lower down where it makes sense to differentiate between the two.IMHO, the method
->exists()
should be a canonical method of determining that an object is properly present in all it's necessary forms. For example, with simple data this method will ensure it's in the database (regardless of how that is actually determined, e.g. simple ID check or actually hitting the DB with a query to verify). For files, this should also presumably look at storage to validate existence.Also, another argument for this is that these two methods (at least in DataObject) are nearly identical:
https://github.com/silverstripe/silverstripe-framework/blob/4.4.4/src/ORM/DataObject.php#L759-L762
https://github.com/silverstripe/silverstripe-framework/blob/4.4.4/src/ORM/DataObject.php#L3802-L3805
I'd like to hash this out since I want to standardize my code on a method like
->exists()
instead of doing a direct check of$obj->ID > 0
since that would likely be impacted if we ever moved to a UUID-based ID system like those discussed or proposed in #6819 and #8411.PRs
The text was updated successfully, but these errors were encountered: