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 <[email protected]> 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 <[email protected]> > 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 <[email protected]> > 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 <[email protected]> > >> 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
