couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Charette <ioma...@yahoo.com>
Subject Re: Google Summer of Code topics
Date Wed, 27 Mar 2013 18:08:10 GMT
>> I don't want to highjack this thread
> 
> Actually I did but I'm not sorry because I think this topic needs more
> discussion and awareness.

Fair enough

> What threw me was your `require`, `exports`, etc., which can't be in an update handler.
 

CouchDB supports commonjs modules.  Don't know what I would do without them!
More here:  http://caolanmcmahon.com/posts/commonjs_modules_in_couchdb/

> It appeared it ran in node not couch.

Oh the beauty of writing couchapps with kanso.  pure awesomeness!  Also works with coffeescript
as I see that is your personal flavor preference of js.
http://kan.so/docs/Using_coffeescript_with_kanso

> @jeff, if you give me permission I will add your solution as a form-based
> partial update that is less complicated.  I will take a shot at turning it
> into the actual js that goes in the handler.
Sounds good and thank you.

Jeff Charette | Principal 
We Are Charette
web / identity / packaging

m  415.298.2707
w  wearecharette.com
e   jeffrey@wearecharette.com

On Mar 27, 2013, at 1:04 PM, Mark Hahn <mark@hahnca.com> wrote:

>> I don't want to highjack this thread
> 
> Actually I did but I'm not sorry because I think this topic needs more
> discussion and awareness.
> 
> I apologize for questioning your code over and over.  I now finally
> understand what you are doing.
> 
> What threw me was your `require`, `exports`, etc., which can't be in an
> update handler.  You also never mentioned the word handler.  It appeared it
> ran in node not couch.  Also after two years of writing in nothing but
> coffeescript I find javascript hard to read.  :-)
> 
> If anyone cares I added a page to the couchDB wiki with my partial updates
> solution.  It is at http://wiki.apache.org/couchdb/Partial_Updates linked
> from the how-to page. It is brand new so let me know what you think.
> 
> @jeff, if you give me permission I will add your solution as a form-based
> partial update that is less complicated.  I will take a shot at turning it
> into the actual js that goes in the handler.
> 
> 
> 
> On Wed, Mar 27, 2013 at 7:44 AM, Jeff Charette <iomatix@yahoo.com> wrote:
> 
>> I don't want to highjack this thread, but also don't want people to get
>> confused.  My code runs on the backend in the updates handler and just
>> looks for matches coming from the request then fills in those results.  Yes
>> you need the id to update and yes you can update only one field or multiple
>> since it overrides the doc.
>> 
>> If you want to discuss more send me a direct thread or if other are
>> interested maybe start a new one.
>> 
>> Jeff Charette | Principal
>> We Are Charette
>> web / identity / packaging
>> 
>> m  415.298.2707
>> w  wearecharette.com
>> e   jeffrey@wearecharette.com
>> 
>> On Mar 26, 2013, at 12:23 PM, Mark Hahn <mark@hahnca.com> wrote:
>> 
>>> The code you provided only runs in the client, not in an update handler,
>>> right?
>>> 
>>> The concept of a DB supporting partial update is to only send the fields
>>> that need to change to the DB instead of the entire doc. There is a real
>>> efficiency advantage to send a few fields over the wire instead of entire
>>> docs.
>>> 
>>> There is also an advantage in having different apps (or parts of one app)
>>> only know about some parts of the doc and never having to know the entire
>>> doc.
>>> 
>>> One example: I have three different node apps that modify a single
>> progress
>>> doc in a single dB based on their work. They are only passed the doc ID
>> and
>>> their job assignment when they start and then they mark their progress in
>>> the doc as they go.
>>> 
>>> 
>>> 
>>> On Tue, Mar 26, 2013 at 7:19 AM, Jeff Charette <iomatix@yahoo.com>
>> wrote:
>>> 
>>>> Now I'm really confused.  Doesn't you approach have the same drawback
>> for
>>>> existing docs?  You have to have the doc id to update the doc don't you?
>>>> 
>>>> For my approach to work, the form has to have the doc id in it yes or
>> for
>>>> new docs I create a new doc based off the type, but that's another
>> exercise.
>>>> 
>>>> I really like your approach for complex data types I just suspect that
>>>> some may only have the need for key value, either way good stuff.
>>>> 
>>>> Jeff Charette | Principal
>>>> We Are Charette
>>>> web / identity / packaging
>>>> 
>>>> m  415.298.2707
>>>> w  wearecharette.com
>>>> e   jeffrey@wearecharette.com
>>>> 
>>>> On Mar 25, 2013, at 3:54 PM, Mark Hahn <mark@hahnca.com> wrote:
>>>> 
>>>>>> You simply post to '_update/edit/docid' with form content.
>>>>> 
>>>>> I don't understand how this works.  Doesn't it require already having
>> the
>>>>> doc and therefore requires a read and an update?
>>>>> 
>>>>> 
>>>>> On Mon, Mar 25, 2013 at 10:47 AM, Pearce, Martyn <Martyn.Pearce@gs.com
>>>>> wrote:
>>>>> 
>>>>>> thank you
>>>>>> 
>>>>>> -----Original Message-----
>>>>>> From: Jeff Charette [mailto:iomatix@yahoo.com]
>>>>>> Sent: Monday, March 25, 2013 5:44 PM
>>>>>> To: user@couchdb.apache.org
>>>>>> Cc: 'CouchDB Developers'
>>>>>> Subject: Re: Google Summer of Code topics
>>>>>> 
>>>>>> I do something similar.  Here it is in case anyone wants to look
at it
>>>>>> from a slightly different code perspective.
>>>>>> 
>>>>>> /* underscore and underscore string are not needed, just my
>> preference
>>>>>> */
>>>>>>  var _ = require('underscore')._,
>>>>>>   _s = require('underscore-string'),
>>>>>>   globalKeys = ['_id', '_rev', 'template', 'type', 'permissions'];
>>>>>> 
>>>>>>  exports.edit = function (doc, req) {
>>>>>> 
>>>>>>      /* add values from request */
>>>>>>      _.each(req.form, function(val, key) {
>>>>>>              if (globalKeys.indexOf(key) === -1) {
>>>>>>                      try {
>>>>>>                      doc[key].value = JSON.parse(req.form[key]);
>>>>>>                  }
>>>>>>                      catch (e) {
>>>>>>                      if (typeof doc[key] !== 'undefined') {
>>>>>>                                      doc[key].value = req.form[key];
>>>>>>                              }
>>>>>>                  }
>>>>>>              }
>>>>>>      });
>>>>>> 
>>>>>>  return [doc, {
>>>>>>      code: 200,
>>>>>>      headers: {
>>>>>>        'Content-Type': 'application/json'
>>>>>>       },
>>>>>>      body: JSON.stringify('render to template or return success')
>>>>>>  }];
>>>>>>  };
>>>>>> 
>>>>>> You simply post to '_update/edit/docid' with form content.
>>>>>> 
>>>>>> Jeff Charette | Principal
>>>>>> We Are Charette
>>>>>> web / identity / packaging
>>>>>> 
>>>>>> m  415.298.2707
>>>>>> w  wearecharette.com
>>>>>> e   jeffrey@wearecharette.com
>>>>>> 
>>>>>> On Mar 25, 2013, at 12:46 PM, "Pearce, Martyn" <Martyn.Pearce@gs.com>
>>>>>> wrote:
>>>>>> 
>>>>>>> thanks
>>>>>>> 
>>>>>>> -----Original Message-----
>>>>>>> From: Mark Hahn [mailto:mark@hahnca.com]
>>>>>>> Sent: Monday, March 25, 2013 4:45 PM
>>>>>>> To: user
>>>>>>> Cc: CouchDB Developers
>>>>>>> Subject: Re: Google Summer of Code topics
>>>>>>> 
>>>>>>> Here is the code in a gist ..
>>>> https://gist.github.com/mark-hahn/5238514
>>>>>>> 
>>>>>>> 
>>>>>>> On Mon, Mar 25, 2013 at 9:00 AM, Pearce, Martyn <
>> Martyn.Pearce@gs.com
>>>>>>> wrote:
>>>>>>> 
>>>>>>>> Posting it here would be a great start.  That would imply
permission
>>>> for
>>>>>>>> interested parties to post it on an examples page, I think.
>>>>>>>> 
>>>>>>>> Thanks,
>>>>>>>> 
>>>>>>>> -----Original Message-----
>>>>>>>> From: Mark Hahn [mailto:mark@hahnca.com]
>>>>>>>> Sent: Monday, March 25, 2013 3:59 PM
>>>>>>>> To: user
>>>>>>>> Cc: CouchDB Developers
>>>>>>>> Subject: Re: Google Summer of Code topics
>>>>>>>> 
>>>>>>>> How would you suggest I publish it?  I don't have a blog.
 I guess I
>>>>>> could
>>>>>>>> post it here for now.  It's not very big.
>>>>>>>> 
>>>>>>>> 
>>>>>>>> On Mon, Mar 25, 2013 at 2:19 AM, Pearce, Martyn <
>> Martyn.Pearce@gs.com
>>>>>>>>> wrote:
>>>>>>>> 
>>>>>>>>> It would be a great published example/howto if you were
willing to
>>>>>>>> publish
>>>>>>>>> your code for that.
>>>>>>>>> 
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: Mark Hahn [mailto:mark@hahnca.com]
>>>>>>>>> Sent: Friday, March 22, 2013 6:14 PM
>>>>>>>>> To: user
>>>>>>>>> Cc: CouchDB Developers
>>>>>>>>> Subject: Re: Google Summer of Code topics
>>>>>>>>> 
>>>>>>>>>> Implement partial reads and updates of documents,
>>>>>>>>> 
>>>>>>>>> In case anyone didn't know, you can do partial updates
right now
>> with
>>>>>> an
>>>>>>>>> update handler.  I have been using one for some time
that allows
>> the
>>>>>> app
>>>>>>>> to
>>>>>>>>> modify any part of a doc with a single http request.
 It even
>> allows
>>>>>> one
>>>>>>>> to
>>>>>>>>> modify an attribute nested inside objects.  I've ended
up using
>> only
>>>>>> this
>>>>>>>>> for all updates.
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> On Fri, Mar 22, 2013 at 7:20 AM, Jeff Charette <iomatix@yahoo.com>
>>>>>>>> wrote:
>>>>>>>>> 
>>>>>>>>>> My top 3 for couchapps:
>>>>>>>>>> 
>>>>>>>>>> 1. more robust _rewrites module to do things like,
possibly
>>>> introduce
>>>>>>>>>> regex matching
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>>> 
>>>> 
>> http://stackoverflow.com/questions/14839422/rewrite-without-file-extension-in-couchdb
>>>>>>>>>> 2. doc level security
>>>>>>>>>> 3. with secure_rewrites true, _attachments handler
moved to design
>>>> doc
>>>>>>>>>> level /db/_design/doc/_attachments - like an update
handler
>>>>>>>>>>     - database level _users, so /db/_design/doc/_users
- behaves
>>>>>>>> just
>>>>>>>>>> like /_users
>>>>>>>>>> 
>>>>>>>>>> Sorry if any of this is pathetically naive!
>>>>>>>>>> Jeff Charette | Principal
>>>>>>>>>> We Are Charette
>>>>>>>>>> web / identity / packaging
>>>>>>>>>> 
>>>>>>>>>> m  415.298.2707
>>>>>>>>>> w  wearecharette.com
>>>>>>>>>> e   jeffrey@wearecharette.com
>>>>>>>>>> 
>>>>>>>>>> On Mar 22, 2013, at 7:13 AM, Dave Cottlehuber <dch@jsonified.com>
>>>>>>>> wrote:
>>>>>>>>>> 
>>>>>>>>>>> Hi folks,
>>>>>>>>>>> 
>>>>>>>>>>> GSOC[1][2] registration for ASF closes this weekend,
and we'd
>> like
>>>> to
>>>>>>>>>>> get some proposals into it, viz
>>>>>>>> http://community.apache.org/gsoc.html
>>>>>>>>>>> from last year.
>>>>>>>>>>> 
>>>>>>>>>>> If you reply, please do so just to the dev@ list
-- note I BCC'd
>>>>>>>>>>> users@ for some ideas.
>>>>>>>>>>> 
>>>>>>>>>>> I've got a few suggestions to get the ball rolling,
with numbers
>>>>>>>> where
>>>>>>>>>>> taken from the future features list:
>>>>>>>>>>> https://gist.github.com/rnewson/2387973
>>>>>>>>>>> 
>>>>>>>>>>> 6. implement a Domain-Specific Language to run
within the Erlang
>>>> VM,
>>>>>>>>>>> to support native speed filtering, validation,
and indexing in
>>>>>>>>>>> addition to the current in-built JS and erlang
ones. Maybe
>>>> something
>>>>>>>>>>> that includes http://jsonselect.org/
>>>>>>>>>>> 
>>>>>>>>>>> 8/9. Rewire CouchDB's HTTP layer to support websockets
and spdy.
>> I
>>>>>>>>>>> think this implies switching to cowboy, this
could be too messy.
>>>>>>>>>>> 
>>>>>>>>>>> 12. Extend CouchDB's query model (e.g.
>>>>>>>>>>> 
>> https://developers.google.com/chart/interactive/docs/querylanguage
>>>> )
>>>>>>>> to
>>>>>>>>>>> support a richer syntax.
>>>>>>>>>>> 
>>>>>>>>>>> 13/14. Implement partial reads and updates of
documents,
>>>>>>>>>>> 
>>>>>>>>>>> Make the javascript view engine faster. Could
include v8
>> bindings,
>>>>>>>>>>> different / parallel communication approaches
between erlang and
>>>>>>>>>>> javascript worlds, avoiding reparsing JSON roundtrips,
and make
>> it
>>>>>>>>>>> faster than the current spidermonkey implementation.
>>>>>>>>>>> 
>>>>>>>>>>> Implement external storage of attachments and
appropriate HTTP
>> API
>>>>>>>>>>> hooks incl replication to allow hosting attachments
outside the
>>>>>>>> .couch
>>>>>>>>>>> files, either on local storage, or in cloud blob
storage (S3,
>> azure
>>>>>>>>>>> etc).
>>>>>>>>>>> 
>>>>>>>>>>> Implement a view development sandbox, where you
can easily
>>>> prototype
>>>>>>>>>>> with a sub-set of documents without long build
times.
>>>>>>>>>>> 
>>>>>>>>>>> Add an optional HTTP compression layer to CouchDB.
It would be
>>>> really
>>>>>>>>>>> cool if you could do the compression during doc
update (or view
>>>>>>>>>>> creation or something) so that it can be served
directly next
>> time.
>>>>>>>>>>> See https://github.com/lgerbarg/couchdb/tree/gzip-support
for a
>>>>>>>> prior
>>>>>>>>>>> implementation or https://gist.github.com/archaelus/76455
for a
>>>>>>>>>>> file-based approach, and
>>>>>>>>>>> 
>>>>>>>>> 
>>>>>> 
>> http://visualstart.blogspot.co.at/2012/02/mochiweb-erlang-and-gzip.html
>>>>>>>>>>> for some other ideas.
>>>>>>>>>>> 
>>>>>>>>>>> Develop a plugin API & rework the authentication
layer to allow
>>>>>>>>>>> plugging in ErLDAP, nodejs with EveryAuth or
PassportJS or in
>> fact
>>>>>>>>>>> anything you like.
>>>>>>>>>>> 
>>>>>>>>>>> Extend geocouch and/or couchdb with some of Volker's
ideas (cue
>>>>>>>>>>> Volker). Or stuff like quadtrees, geohashes or
hilbert curves.
>>>>>>>>>>> 
>>>>>>>>>>> Finally, if you are interested in being a mentor,
please speak
>> up!
>>>>>>>>>>> 
>>>>>>>>>>> A+
>>>>>>>>>>> Dave
>>>>>>>>>>> 
>>>>>>>>>>> [1]: http://www.google-melange.com/gsoc/homepage/google/gsoc2013
>>>>>>>>>>> [2]:
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>>> 
>>>> 
>> https://groups.google.com/forum/?fromgroups=#!topic/google-summer-of-code-discuss/yYM2ru4bTeo
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>>> 
>>>>>> 
>>>> 
>>>> 
>> 
>> 


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message