dots in charm names (shelr.tv)

[Kapil Thangavelu]

On Tue, Mar 26, 2013 at 11:44 AM, Gustavo Niemeyer <
gustavo.niemeyer at canonical.com> wrote:

> On Tue, Mar 26, 2013 at 3:32 PM, Kapil Thangavelu
> <kapil.thangavelu at canonical.com> wrote:
> > afaics the best way to ensure this divergence doesn't happen is to use
> the
> > go charm definition for validation of a charm and incorporate that into
> > charm-lint/charm browser, or alternatively to put an interface on the
> charm
> > store to collect the errors for a given charm branch there.
>
> No, the best way to ensure this divergence doesn't happen is to check
> the store to see if a charm exists. This is very trivial to do, and
> very effective too. Anything else will open the door for headaches.
>

The charm browser does do this check and stores it against the charm
although its not currently limiting visibility on this alone. It should do
that though (bug 1160527). The issue is that we have no feedback mechanism
for users from the store, so at times it can be opaque as to what the
actual issue is with the appearance in the charm store, unless that rule is
also encoded into the charm-lint tool, or into the review queue/lint
reports on the browser. The mechanism i suggested was to avoid this
divergence of rules  by incorporating the store processing directly into
the feedback mechanisms we have for charm authors.


> > incidentally the mongodb issue is a pymongo driver thing, previous
> versions
> > of the driver where able to handle '.' in values without issue.
>
> There's more to it than that. The dot is used in several places in
> MongoDB to define sub-document access.
>

indeed, and that was likely the cause for the driver change to remove
ambiguity, but it also implies mongodb can handle such values.

cheers,

Kapil
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju/attachments/20130326/14b9bfdc/attachment.html>