From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by sourceware.org (Postfix) with ESMTPS id 189D63857404 for ; Mon, 21 Mar 2022 20:24:21 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 189D63857404 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=serhei.io Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=serhei.io Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 29F965C01FE; Mon, 21 Mar 2022 16:24:19 -0400 (EDT) Received: from imap50 ([10.202.2.100]) by compute5.internal (MEProxy); Mon, 21 Mar 2022 16:24:19 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=serhei.io; h=cc :cc:content-type:date:date:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to; s=fm1; bh=VoFxgH7HGlW+3FTt+n9NJFo7EGvWeBzjZRkBOe xSaqI=; b=rHVmBVsXzQCHw7tGIG/oIZp6XsDM6cMx9kE5e5Fim0bo/83xbpAXkR S5Yr0UZoHLJF8V7r+GSyt0v6AiXq4EE39JIp/n0Jb60tOA9FRp9Orbxkq43mHyAx L6oRBUuKPRbEZY5nJ0vB4RKBrpa2ieS1SNFu39+CsDjlrumHp7Ktk9vB+wW08+RW TPiV2kng/yFBtO95kYiF0yL0Yi0SDzDaRWLiHT21fAs1ljwaSjcOE0b3G/NM7qeY l2ttji8b6jUjop8IPT30EsvIydu4jiWzZvE2wKD1W5o3bIiU+PVYmXla142ONABS +SYy7msc3bZ5zTNL1D7t58Fra3SPqBtA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=VoFxgH7HGlW+3FTt+ n9NJFo7EGvWeBzjZRkBOexSaqI=; b=R4kqeIt2fgaABmtsi1VSNTnoTyM4Fnf/Z FhergmSLyhR7OlDX6mmNIdg7IgaTX7cXILGrV6u4mTKf4poghUUB3lQ/pfQPuiE2 sqbszFFy9pYe44abMW2/d/9S+lC+tPIax6US1zLRnb6IY6HAIcDdQFAIKe/BzbXv u0B6dAzjSLccZJGGQXeKaAc52ddfzOinmOcWerxtnhU7j71QUVcVk+phgx1fy+RP DHojaUlsWhXEma1ehhmFcUm2knVLhpU/XEhDUG7ZvAzDh6xXBYVpQL5FBRqCrx7q k37lt9+R8zgGMkiqCoGdvfgmXbTQ2kZoTeKMZBXTZ/IMQfzz5xfvA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvvddrudegfedgudefjecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesth dtredtreertdenucfhrhhomhepfdfuvghrhhgvihcuofgrkhgrrhhovhdfuceomhgvsehs vghrhhgvihdrihhoqeenucggtffrrghtthgvrhhnpeefjefggfegffduheeitdeltdegje dtkefgueelhedutdfggedvgffhjeekiefgtdenucevlhhushhtvghrufhiiigvpedtnecu rfgrrhgrmhepmhgrihhlfhhrohhmpehmvgesshgvrhhhvghirdhioh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id CBC76192833C; Mon, 21 Mar 2022 16:24:18 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-4907-g25ce6f34a9-fm-20220311.001-g25ce6f34 Mime-Version: 1.0 Message-Id: <01b56f84-b5fe-4d4b-8cca-20df69a1bb0c@www.fastmail.com> In-Reply-To: <87r16vdr8u.fsf@redhat.com> References: <1796a6e2-2b2a-49a7-b350-9d58700d3e30@www.fastmail.com> <87r16vdr8u.fsf@redhat.com> Date: Mon, 21 Mar 2022 16:23:52 -0400 From: "Serhei Makarov" To: "Frank Ch. Eigler" Cc: Bunsen Subject: Re: bunsen (re)design discussion #2: Repository Layout, SQLite design idea + Django-esque API(?) Content-Type: text/plain X-Spam-Status: No, score=-3.6 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, JMQ_SPF_NEUTRAL, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_PASS, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: bunsen@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Bunsen mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2022 20:24:22 -0000 On Mon, Mar 21, 2022, at 3:45 PM, Frank Ch. Eigler wrote: > (We seem to be converging on accepting any loosely structured git repo > for storage of the raw testresult data, which should make it easy for > varied tooling to submit data.) Yes, I have no problem with coding support for that into the design, accepting test logs from a Git repo with free-form format and putting parsed testrun data elsewhere. For my concern re: cloning (full or partial) it does not complicate things. >> Given the toss-up and potential complementary strengths, it would be >> best to have a way to support both formats and experiment extensively. > > What could make sense is to have a dual API. A secondary storage format > that tools can consume (not just ours), and a programmatic python API > bound to that stuff for those types of operations that are best written > procedurally. > ... > Well, I hope through discussion and experiment, we settle on one or the > other, before exposing this decision to our users. The current model API is not "bound to" JSON the same way an embedded-SQL analysis script would be bound to SQL. Thus far I have completely avoided handling JSON format directly in the analysis, doing everything through the model classes, which could be coded against either JSON or SQL.