search

SpiNNakerManchester / SpiNNFrontEndCommon

Common support code for user-facing front end systems.
Apache License 2.0
12 stars 11 forks source link

Reports as database #657

Closed rowleya closed 1 year ago

rowleya commented 4 years ago

It could be more useful to have some of our reports as part of the provenance database (or as a separate database, though this would be less useful). For example, the placement information might work better this way.

alan-stokes commented 4 years ago

the live io database i guess has the info for this to be a view on its data. But a question that comes to mind, is these are 1 per run, not many based off size of network. why do the work to bring them into a new database?

rowleya commented 4 years ago

We already generate reports on this; having those in a database is more useful for post-execution analysis. We do have the live io database, but this isn't automatically generated, whereas the reports are. Also this is then a separate database, where having a single one allow you to do more joined up querying.

alan-stokes commented 4 years ago

more usful for post execution analysis i can go with. but the other current database we write, i dont think has the data youd need, its possible to generate ALL the reports we currently have as database views, that you'd need basically whats in that database. thus why it comes to mind to put them in that database and now make that default on when any report is on?

writing a 3rd database would slow things down, esp if its during the time when we do have that one being written.

rowleya commented 4 years ago

Sorry misunderstood; I fully support not having another database! If you think that default enabling the live I/O database will solve this, that sounds good to me. It should then probably be integrated with the provenance database maybe though, since that also contains things that could be cross referenced e.g. how many dropped packets to I get from chips with this Population on it?

alan-stokes commented 4 years ago

you could.....but now your going to end up moving a lot of support around which could break backwards compat, coz we put that io database in a specific location. (that said, we're always said to use the eieio protocol for the path, so maybe its not that big of a issue).

maybe,

dkfellows commented 1 year ago

Provenance data now goes to a DB.