polygene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niclas Hedhman <nic...@hedhman.org>
Subject Re: @Queryable(false)
Date Thu, 14 Apr 2016 07:45:11 GMT
Considering the large amount of users, I think it is a great time to
reconsider anything.

Anecdote; A long time ago, I was involved in designing a protocol and
device using that protocol on serial line. When I came in, the technology
used could only handle 32 devices on the RS-485, address 0-31. The boss had
already decided that 31 was a broadcast address that everyone answered on,
and that 30 was the default address from factory. Before we shipped, we
added a second address mechanism (kind of 'which network'), so again boss
thought that 255 for broadcast and 254 for default adress was good. And
then the electronics got better and could handle way more than 32 devices,
so software-wise we stop limiting the device address. And we had 254:30 as
default address and 255:31 as the broadcast address. And that remained
until I was tasked to rewrite the network stack. And I suggested that 0:0
was going to be used for broadcast and 255:255 as default address because
every packet had to check for "is it me" and "is it broadcast", and the
latter could be done with a
   AND a,b

compared to a lengthy, check each byte against two different immediate
numbers (possibly 10us instead of 2us or so).  The boss said; "No way. We
have so many units delivered and it is not reasonable to change this now.",
and yeah, we had probably 100 devices shipped and installed. But, the
amount of time spent to explain why 254:30 and 255:31 was used for these
cases, to all future customers (100s of companies, 100,000s of devices) has
been a lot more troublesome.

Long story for a small point; I don't think we need to be afraid to scare
away users. The main pain is updating the documentation.


On Thu, Apr 14, 2016 at 2:44 PM, Kent SĂžlvsten <kent.soelvsten@gmail.com>

> Hi Niclas!
> Sorry I have not been of much use lately.
> The job-giving-bread-on-the-table-requiring some attention.
> I agree that defaulting to everything being queryable is a lousy default.
> Beginning from scratch today, I would have preferred the opposite
> default, and an @Indexed annotation.
> The opposite default, and i think it better communicates the machinery
> below.
> In a distant future we could then consider adding (optional) attributes
> to the annotation, such as
> @Indexed(name="login" order=1)
> @Indexed(name="employee" order="1")
> Property<String> name();
> @Indexed(name="login" order=2)
> Property<String> password();
> @Indexed(name="employee" order="2")
> Association<Company> company();
> @Indexed
> Property<String> email();
> acting as a hint that we should expect queries by name-and-password,
> name-and-company or by email.
> Some implementations might be able to use these hints to improve
> performance.
> But I am more uncertain whether we should switch the default now or be
> bound by the old decision.
> /Kent
> Den 14-04-2016 kl. 07:46 skrev Niclas Hedhman:
> > Firstly, It feels a little bit icky to have a "true" default and a
> long-ish
> > declaration with false to disable it.
> >
> > Secondly, it is possibly somewhat misleading to say that it is not
> > Queryable. In fact, it is not being indexed, which results in not
> > searchable/queryable.
> >
> >
> > I would like to come up with better naming, if possible.
> >
> > Also, I think it is a valid question to ask; Was it a correct decision
> > "back-when" to default all Properties and all Associations to always be
> > indexed?? Now is the time to consider this choice.
> >
> > Cheers

Niclas Hedhman, Software Developer
http://zest.apache.org - New Energy for Java

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message