It should be strict by default. People who write code are trained to be
careful (or should be). Interactive environments can set it to lax, if they
want, for their user base.
On Sun, Jul 24, 2011 at 8:25 PM, Eric Evans wrote:
> On Sun, 2011-07-24 at 11:33 +0300, David Boxenhorn wrote:
> &
I meant "lax mode" not "lax version".
On Sun, Jul 24, 2011 at 11:33 AM, David Boxenhorn wrote:
> Could we have a strict mode that would enforce quoting terms (this would be
> used in code) and a lax version that could be used in interactive mode,
> where bac
Could we have a strict mode that would enforce quoting terms (this would be
used in code) and a lax version that could be used in interactive mode,
where backward compatibility is not so important?
On Sat, Jul 23, 2011 at 6:39 PM, Eric Evans wrote:
> On Fri, 2011-07-22 at 21:29 -0500, paul cann
be interested in - i.e. news - and chatter (even
the good kind).
On Wed, Jul 20, 2011 at 8:22 PM, Edward Capriolo wrote:
> On Wed, Jul 20, 2011 at 12:48 PM, David Boxenhorn >wrote:
>
> > I am not going to argue the point, because it's not really the point that
> I
> >
useful blog posts by others in the community could be posted.
>
> Ed
>
> On Wed, Jul 20, 2011 at 9:21 AM, Jonathan Ellis wrote:
> > That's exactly the kind of thing that *shouldn't* be on an announce
> > list (and stay on the dev list), precisely because it deals
ercolumns if you don't know what you're
> doing, because almost everyone who does is doing it for the wrong
> reasons.
>
> If you are using Supercolumns for the right reasons (or even the wrong
> ones) you don't need to worry because the API is NOT going to change.
>
>
t; internals that users don't care about.
>
> On Wed, Jul 20, 2011 at 11:18 AM, David Boxenhorn
> wrote:
> > I would like to see this list also used for announcing upcoming features.
> At
> > some point a decision is made that some future version will include some
> &g
I would like to see this list also used for announcing upcoming features. At
some point a decision is made that some future version will include some
important feature. I don't want that information to be buried in a JIRA
ticket or a user/dev list discussion.
For example, I was surprised to learn,
You should include the first link in the second, maybe as a bullet in step
4, e.g.:
- If you're looking for ticket to work on, check out our low-hanging-fruit
list:
https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+12310865+AND+labels+%3D+lhf
On Tue, Jul 5
How about BigDoubles and BigIntegers?
On Tue, Jun 28, 2011 at 3:16 AM, Jonathan Ellis wrote:
> I don't think you can avoid that.
>
> I'd suggest making it CQL-only if we do doubles -- no backwards
> incompatibility required there.
>
> On Mon, Jun 27, 2011 at 7:07 PM, Jason wrote:
>> Sorry, I sho
There was some opposition to the name CQL due to name conflicts.
May I suggest "Cassquel"? I think it has a nice sound.
On Fri, Mar 18, 2011 at 9:54 PM, Eric Evans wrote:
>
> With 3 weeks and change until the branch-and-feature-freeze, I thought
> I'd take a few moments to update everyone on th
I installed this version and ran nodetool scrub on a CF where I suspected
this problem. I got the following error:
root@ubuntu7:/usr/local/cassandra/conf# nodetool scrub System0 Attractions
Error occured while scrubbing keyspace System0
java.util.concurrent.ExecutionException: java.io.IOError:
j
Eventual consistency is not good enough for instant messaging.
On Sun, Nov 21, 2010 at 6:32 PM, Simon Reavely wrote:
> (Posting this to both user + dev lists)
>
> I was reviewing the blog post on the facebook engineering blog from nov
> 15th
> http://www.facebook.com/note.php?note_id=454991608919
Guys, this is beginning to sound like MUMPS!
http://en.wikipedia.org/wiki/MUMPS
In MUMPS, all variables are sparse, multidimensional arrays, which can be
stored to disk.
It is an arcane, and archaic, language (does anyone but me remember it?),
but it has been used successfully for years. Maybe we
14 matches
Mail list logo
