From bloodhound-dev-return-1517-apmail-incubator-bloodhound-dev-archive=incubator.apache.org@incubator.apache.org Mon Jan 7 01:32:19 2013 Return-Path: X-Original-To: apmail-incubator-bloodhound-dev-archive@minotaur.apache.org Delivered-To: apmail-incubator-bloodhound-dev-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 27480ED94 for ; Mon, 7 Jan 2013 01:32:19 +0000 (UTC) Received: (qmail 37484 invoked by uid 500); 7 Jan 2013 01:32:19 -0000 Delivered-To: apmail-incubator-bloodhound-dev-archive@incubator.apache.org Received: (qmail 37412 invoked by uid 500); 7 Jan 2013 01:32:18 -0000 Mailing-List: contact bloodhound-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: bloodhound-dev@incubator.apache.org Delivered-To: mailing list bloodhound-dev@incubator.apache.org Received: (qmail 37397 invoked by uid 99); 7 Jan 2013 01:32:18 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 07 Jan 2013 01:32:18 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=5.0 tests=RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of gary.martin@wandisco.com designates 74.125.82.180 as permitted sender) Received: from [74.125.82.180] (HELO mail-we0-f180.google.com) (74.125.82.180) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 07 Jan 2013 01:32:10 +0000 Received: by mail-we0-f180.google.com with SMTP id t57so9165089wey.39 for ; Sun, 06 Jan 2013 17:31:48 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding :x-gm-message-state; bh=mNDNsWB2lSmPnWfPYPRTSjsFf0VRQTuBNa/Oi0bHiQo=; b=UKthk7iE4+LMT+QT9LjmOOeQojzci0zvxE0NGznNI9pWMmq1E3jXBlHWBNznKq0G4E OUgBMBvhlmCwR1cVpL3e2XucPGdshVq9tRnkuvGdi6+yc/nl8Ff8geinNVRcyuLajs0Q TMw1yFuGv1HwbdsZzIAXIFBz/e80zaoNcEVTlBQdXefzV8pDXUcDvWrt4xGjc99pnWLM 3127GyrhFLs8k2Kqq0nIdLh4nyCnQXl4Rn2QMDjpGQddCEWIkyLIN7eGwNkWujRReivP VYuzaY+Flbf3qoYvf/t26TkzOHPxIxsG2/ykFJ2TV16/BmeifL2afpk1UAwfttnnx2ZE WWvw== X-Received: by 10.180.75.208 with SMTP id e16mr6835855wiw.3.1357522308711; Sun, 06 Jan 2013 17:31:48 -0800 (PST) Received: from [192.168.1.202] ([87.114.88.29]) by mx.google.com with ESMTPS id h19sm9893866wiv.7.2013.01.06.17.31.47 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 06 Jan 2013 17:31:48 -0800 (PST) Message-ID: <50EA2582.8040100@wandisco.com> Date: Mon, 07 Jan 2013 01:31:46 +0000 From: Gary Martin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: bloodhound-dev@incubator.apache.org Subject: Re: [BEP-0003] Request for comments : DB configuration vs ConfigParser References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQkx6t6+7J50U5ECF0us2PEqQN8uFKnwlfYr0wq7WC3+6iXKdwmGrG1cIIJjsP3JyrAt5/Ly X-Virus-Checked: Checked by ClamAV on apache.org On 04/01/13 23:11, Olemis Lang wrote: > While working on #115 I've tried to keep new config objects interface > identical to Trac's . Nonetheless the later have two levels of caching > : > > 1. `_cache` instance method > 2. Mapping object(s) used under the hood by ConfigParser instance > used to load INI file (e.g. trac.ini) > > This means that write operations on configuration files only touch (2) > in first place and changes are not persisted until after save() method > is invoked . > > The circumstances for multi-product configuration are a bit different > considering the fact that settings will be stored in the DB . So in > that case I'm considering the possibility of commiting changes right > away to the DB rather than having a second-level cache since the later > approach will make things easier afaics . Nonetheless that will break > somehow the contract of `trac.config.Configuration` type , ... > > ... so I'd like to know beforehand if anybody has anything to say > about that subject . Comments ? Objections ? > I am interested in the scope of configuration that we are aiming to achieve here. Are we only going to be considering a limited set of options so that per-product settings cannot cause conflicts or are we likely to go much further than this? I have no particular problem with the db only approach although I would be tempted to add a cli admin command to dump and load settings for a specified product. Cheers, Gary