Skip to content
This repository has been archived by the owner on Feb 20, 2024. It is now read-only.

Better events and exceptions #90

Open
Nyholm opened this issue Nov 9, 2015 · 12 comments
Open

Better events and exceptions #90

Nyholm opened this issue Nov 9, 2015 · 12 comments
Milestone

Comments

@Nyholm
Copy link
Collaborator

Nyholm commented Nov 9, 2015

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 each DatabaseInterface and dumps it.
  • ProcessorManager does 3 things. It copies folders, compresses files and removes backup files.
  • ClientManager steps throw each ClientInterface 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:

Event object Properties Event names (draft)
DatabaseEvent name, path DumpCompleted
ProcessorEvent name, path CompressFilesCompleted
FilesystemEvent filename FilesCopied, FilesRemoved
UploadEvent name, filname[] UploadCompleted
BackupEvent timeToFinish BackupCompleted
BackupFailedEvent name, type, message, timeToFail BackupFailed

With these new events a user could easily:

  • Verify that the upload is completed (UploadEvent)
  • Copy in more files to the zip (FilesystemEvent)
  • Calculate hashes for the compressed files ( ProcessorEvent)
  • Notify other services that the backup has happened (BackupEvent)
  • etc etc.

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

@dizda
Copy link
Owner

dizda commented Nov 10, 2015

Looks great!

Just realized that we may need the filename of the backup in BackupEvent?

@Nyholm
Copy link
Collaborator Author

Nyholm commented Nov 10, 2015

Hm, tell me more. Why should filename be in the BackupEvent?

@dizda
Copy link
Owner

dizda commented Nov 10, 2015

When you got many projects you might want to know which backup has been completed

@Nyholm Nyholm added this to the 4.0 milestone Nov 10, 2015
@Nyholm
Copy link
Collaborator Author

Nyholm commented Nov 10, 2015

The UploadEvent is dispatched after a file it uploaded. It might be one or it might be 100 files on 4 clients.
We can not use filename in Backup event since we don't know how many files or if they still are named the same.
We could however use the output_file_prefix or a variant of that... But... tell me more. Where are you looking when you "want to know which backup has been completed". In a centralized logger? Don't you see from which project the logging messages comes from? I don't quite understand.

@jongotlin
Copy link
Collaborator

What BackupEvent could have as a property is how long it took the operation to finish.

@Nyholm
Copy link
Collaborator Author

Nyholm commented Nov 10, 2015

Is that interesting for all events?

@jongotlin
Copy link
Collaborator

Only for those that actually may take some time.

@dizda
Copy link
Owner

dizda commented Nov 10, 2015

@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?

@Nyholm
Copy link
Collaborator Author

Nyholm commented Nov 10, 2015

The UploadEvent is dispatched from the ClientManger it will know of the filenames.

But do you think it is within the scope of the BackupEvent to know all the filenames that was uploaded?
Or, maybe it makes sense to have an array of filenames in the BackupEvent form a DX perspective. It is a lot easier that collect info from UploadEvent and then take action as soon as BackupEvent is dispatched.

@dizda
Copy link
Owner

dizda commented Nov 10, 2015

Oh ok I get it.
So you suggest to add an event listener on both events to get the filename from the BackupEvent?

@Nyholm
Copy link
Collaborator Author

Nyholm commented Nov 10, 2015

Yeah, That was my suggestion but I'm reconsidering it now. Because we might do things too complicated for the users.

@ZCJ
Copy link

ZCJ commented Dec 22, 2016

so how would you get now the backup file name that is created?
I understand that there is only 1 event dispatched upon success and the event itself does not have any information.

if ($successful) { $this->eventDispatcher->dispatch(BackupEvent::BACKUP_COMPLETED, new BackupEvent()); }

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.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants