Great! I just left a note in that ticket about leveraging folsom as a metrics engine. Cheers,
Adam On May 29, 2013, at 12:25 PM, Pavan Sudheendra <pavan0...@gmail.com> wrote: > Oh ok. > > I think i'll go forward with COUCHDB-1751. > I am to submit a draft or proposal on how i'll go forward with this > implementation as Dave suggested. > > I will send the proposal to the group by tomorrow or day after max. Do take > a look and suggest changes :) > > I'm very excited about contributing. > > Thanks Adam :) > > > On Wed, May 29, 2013 at 9:48 PM, Adam Kocoloski <kocol...@apache.org> wrote: > >> I think the aliasing feature might can moderately complicated, yes. I >> suspect the final implementation will be straightforward, but you have to >> wade pretty deep into core. >> >> COUCHDB-1751 is a great ticket. The challenges there are a) it needs to >> be very high-performance, and writing high-performance Erlang code can be >> tricky, and b) a number of folks have pretty strong opinions about how it >> should work. Don't want to discourage you from tackling it, though! It'd >> be great to export metrics more easily. >> >> Adam >> >> On May 29, 2013, at 11:52 AM, Pavan Sudheendra <pavan0...@gmail.com> >> wrote: >> >>> Hi Adam! >>> >>> Thanks for replying. Yes, i got a gist of it. Haven't read upon BigCouch. >>> Must do that now. >>> >>> Overall, do you think this feature addition is very complicated? I cannot >>> say i'm an expert in coding so making sure i don't take up a feature >> which >>> is very difficult to implement. >>> >>> Also, your thoughts on >> https://issues.apache.org/jira/browse/COUCHDB-1751 ? >>> >>> I believe giving some stats to third party application like Graphite >> etc,.? >>> >>> >>> On Wed, May 29, 2013 at 9:05 PM, Adam Kocoloski <kocol...@apache.org> >> wrote: >>> >>>> Hi Pavan! >>>> >>>> In my opinion COUCHDB-1735 is superseded by COUCHDB-1736. If we have an >>>> aliasing system then a rename can be something like an alias creation >> and >>>> deletion. >>>> >>>> In the description on COUCHDB-1735 Dave mentions that the BigCouch code >>>> may complicate this feature addition. I'm biased, but I actually think >> it >>>> provides a really nice place to implement it. In the BigCouch world >> every >>>> logical database has a "partition table" that lists the names and >> locations >>>> of the shard files that comprise it. That partition table is stored as >> a >>>> document in a special system DB which is replicated to every node in a >>>> cluster. >>>> >>>> I believe we can implement aliases as partition table documents that >>>> either point to the "canonical" partition table document for the DB (the >>>> "ln" option) or else list the original shard names explicitly (the "cp" >>>> option). >>>> >>>> Does that make sense? >>>> >>>> On May 29, 2013, at 11:23 AM, Pavan Sudheendra <pavan0...@gmail.com> >>>> wrote: >>>> >>>>> Hi all, >>>>> >>>>> I've been in constant touch with Dave and i'm all set to contribute in >>>> some >>>>> way or another :) >>>>> >>>>> I wanted to ask you all about this but couldn't attend the IRC meet >> today >>>>> for some reason. >>>>> >>>>> I need your input on these bugs. >>>>> >>>>> 1. https://issues.apache.org/jira/browse/COUCHDB-1736 Database >> Aliases. >>>>> >>>>> 2. https://issues.apache.org/jira/browse/COUCHDB-1735 Allow Database >>>>> renaming. >>>>> >>>>> Can you please explain what might be the issues i'd face if i took >> these >>>>> bugs on? >>>>> >>>>> Database renaming conceptually looks simple, move or copy all the >>>> documents >>>>> of the database into a seperate view and delete the previous database. >> Is >>>>> there something which i'm missing? I know there is a lot more to this. >>>>> Would be glad if someone explained to me how its going to be. >>>>> >>>>> What about Database Aliases? >>>>> >>>>> Any help will be greatly appreciated. >>>>> -- >>>>> Regards- >>>>> Pavan >>>> >>>> >>> >>> >>> -- >>> Regards- >>> Pavan >> >> > > > -- > Regards- > Pavan
