Stephan van Hulst wrote:Yes, that's a good strategy. There's actually a pretty good way to deal with this if you're in control of most of the layers, and if you can design consistent APIs.
Stephan van Hulst wrote:Like I said, for unchecked exceptions it doesn't really matter that much, because they're caused by bugs in your application that necessary will be have to fixed by a programmer, not by the end user. A generic message will do, if you don't want the application to crash catastrophically.
For checked exceptions, the code knows ...
Stephan van Hulst wrote:Even then, if you want to prevent a long chain of checked exceptions, you can throw a checked exception that's appropriate for your abstraction layer, and as its underlying cause pass the cause of the wrapper that you caught. If you do that consistently, there will only be two exceptions: The wrapper that's appropriate for your abstraction layer, and the underlying cause that's at the very root of the issue:
Jeanne Boyarsky wrote:After three days of no replies, I suspect there isn't a better approach. Which is certainly possible. Maven is big on "the Maven way". And then the IDE doesn't exist so it isn't a problem to change the files in the original source directory.
Dave Tolls wrote:Creating indexes, and getting the correct indexes on a table are how you handle large data sets.
By "registries" do you mean "rows"?
If so, then 27 million, especially if most of them are in tables that only have primitives (eg numbers) that were previously in your ARRAY columns, is not a great deal.
Those tables will be quick look ups, with the correct indexing.
Junilu Lacar wrote:Not everything that is machine readable has to be in binary format. JSON, for example, is machine readable as well as human readable. It's machine readable because it has a specific format that can be processed programmatically. CSV is another machine readable format. Properties (key=value pairs) are also machine readable. Free formatted prose does not lend itself well to being machine readable with current technology. You'd need to have some kind of natural language parser and interpreter. Maybe IBM Watson will lead us there someday, but I digress. Anyway, I hope that clarifies what I meant.
Tim Cooke wrote:In your other topic about Logging I mentioned that the company I currently work for uses Splunk to capture the logging output from application servers. I also mentioned that it also serves as a pretty darn good data analysis tool too. Well Splunk loves key=value pairs and is really good at finding them quickly, so taking your example I could write a simple search for "sessionId=97fd45ef21225b079967efd" to obtain an audit of everything that occurred during that user session.
Les Morgan wrote:I like your format better, and I agree: it is a difference audience that you write for when you do log files--people that read them tend to be more left brain dependent, so more info in a smaller space is better instead of flowery sentences.
Junilu Lacar wrote:You can take it a step further and format all or a subset of your log messages so that they are machine readable. That way, it's easier to automate. You could put a marker on the machine-readable log messages or you could append them to a separate log altogether.
Junilu Lacar wrote:The applications I support log most user activity. We also have very long User Agreements that users need to accept when they sign up and use our apps.