couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adam Kocoloski <kocol...@apache.org>
Subject Re: Information regarding bugs!
Date Wed, 29 May 2013 16:18:48 GMT
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 <pavan0591@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 <kocolosk@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 <pavan0591@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


Mime
View raw message