1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 <2013> 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 2025 | Index | 1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 <2013> 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 2025 |
<== Date ==> | <== Thread ==> |
---|
Subject: | RE: Electronic Logbooks |
From: | Emmanuel Mayssat <[email protected]> |
To: | Miroslav Pavleski <[email protected]> |
Cc: | "[email protected]" <[email protected]> |
Date: | Thu, 1 Aug 2013 00:47:01 -0700 |
As I have been reading about all the alternatives that were suggested (elog, olog, drupal, etc), maybe one of the best features of couchdb is the nosql part, i.e. there is no schema. As a result, you can develop as you go.
That's a major difference in the development process. In practical terms that means no need to anticipate what your future needs will be, no need of front-end collaborations. Instead start implementing immediately based on what your needs are ... today. For example, if on day 1 my log entries consist of just 2 fields (0) date entry was submitted (automatically generated on server side) (1) operator name (2) text content of log entry what if on the next day, I decided to also log in the logbook alarms with high severity level? Obviously, with a logbook based on a SQL database, I can't without reworking the schema (i.e. create a severity column + stuff dummy values for previous entries' severity). That's a major change on a live database. With couchdb, you don't need to touch the database, the process is as follow: You keep all the code you have written on other logbook clients the same. From the alarm handler (new logbook client), you use the REST interface to send for each high severity alarms what you think are meaningful JSON parameters (1) application name (2) alarm level (3) alarm info On the server, you rewrite your MapReduce query (nosql equivalent to an sql query) such as: give me all the documents where application name = alarm handler or where there is an 'operator name' field. Send all those documents in a chronological order to the view In template view, for each document * if there is a field alarm = hihi, print text and set background color to red * if operator name field exist, then display operator's picture and content of the log entry To summarize the only change required on the server side is in your MapReduce query and your template. You don't touch the database. That's 1 hour at most and if you don't use the production query/template for testing, the logbook can stay live! The couchdb will take absolutely anything you provide on its REST interface. The REST interface is itself configurable (URL format + format of provided content (xml/json/...)) You can have several REST interfaces for the same database That means whatever the REST interface for olog-CSS integration is, it can be hijacked by couchdb.... tomorrow -- Emmanuel > Date: Tue, 30 Jul 2013 10:43:36 +0200 > From: [email protected] > CC: [email protected] > Subject: Re: Electronic Logbooks > > Hi > > Thank you all very much for the input! > > Emmanuel, what you propose looks like interesting idea, we'll try this > out as well. > > With Regards, > Miroslav |