-
Notifications
You must be signed in to change notification settings - Fork 56
Better events and exceptions #90
Comments
Looks great! Just realized that we may need the filename of the backup in |
Hm, tell me more. Why should filename be in the BackupEvent? |
When you got many projects you might want to know which backup has been completed |
The UploadEvent is dispatched after a file it uploaded. It might be one or it might be 100 files on 4 clients. |
What |
Is that interesting for all events? |
Only for those that actually may take some time. |
@Nyholm Hmm as far as I know, we only upload one archive to many destinations, so we know what will be the filename of the backup, right? |
The But do you think it is within the scope of the |
Oh ok I get it. |
Yeah, That was my suggestion but I'm reconsidering it now. Because we might do things too complicated for the users. |
so how would you get now the backup file name that is created?
The reason I need the file name is that I need to send an email to the admin to inform him that the backup file (XXX) has been created and uploaded to storage. |
This is a suggestion to which events we should dispatch and exceptions we should throw. Please work with me and give me feedback.
What events to we got?
An event describes a thing that has happened. The event should be broad casted and not modified (you cant modify a radio borad cast). Nor should priority matter.
So, looking at our bundle. What does it? What happens?
The only place we do stuff is in the Managers. We have 3 managers and one "manager manager" (
BackupManager
).DatabaseManager
steps throw eachDatabaseInterface
and dumps it.ProcessorManager
does 3 things. It copies folders, compresses files and removes backup files.ClientManager
steps throw eachClientInterface
and upload every file.BackupManager
handles Exceptions had initiate the next step in the process.(We should extract the filesystem actions from the
ProcessorManager
)I suggest events accordingly:
DatabaseEvent
ProcessorEvent
FilesystemEvent
UploadEvent
BackupEvent
BackupFailedEvent
With these new events a user could easily:
What exceptions might occur?
I suggest we should create these exception classes and then make sure that our managers do not throw any other exceptions.
DatabaseException
ProcessorException
FilesystemException
UploadException
All of the above should implement
BackupException
.Centralized logging.
With these events we could centralize the logging into an event listener. We could also make sure to catch and logg all exceptions from the
BackupManager
The text was updated successfully, but these errors were encountered: