Fwd: Git status update

[Dmitriy Setrakyan]

FYI

Can we delete the unused GIT branches now?

D.

-- Forwarded message --
From: David Nalley 
Date: Sun, Jan 10, 2016 at 10:00 AM
Subject: Git status update
To: "infrastruct...@apache.org" 


Greeting PMCs:
(bcc to p...@apache.org)

Following direction from the Board, Infrastructure has modified git to
permit force pushes, and branch/tag deletion.

In accordance with the guidance that the Board we've implemented a few
changes you should be aware of:

First, If a forced commit is pushed, the subsequent commit email will
contain '[Forced Update!]' in the subject line. The hope here is that
it draws extra attention to the situation for a project community to
be aware, and take appropriate action if needed.

Second, we've changed the 'protected' portions of git to primarily
focus on refs/tags/rel - thus any tags under rel, will have their
entire commit history. This provides the provenance that the ASF needs
for releases, while still giving projects the ability to mold their
repository in the way they see fit.

Thus when a release vote is successful - part of the release process
should become tagging the voted upon commit SHA under rel/ to make it
indelible. ('# git tag rel/v15.4.2 ' or something similar.)


If you have questions, please feel free to email infrastruct...@apache.org


--David
on behalf of Apache Infrastructure

Re: Javadoc link need to be updated

[Dmitriy Setrakyan]

Thanks! I removed the “beta” annotation.

D.

On Sat, Jan 9, 2016 at 5:20 AM, 李玉珏@163 <18624049...@163.com> wrote:

> Hi
>
>
> I note that the version number of the online manual is still in the beta
> state.
>
>
>
> 在 16/1/9 01:19, Dmitriy Setrakyan 写道:
>
> Thanks Roman! I updated the link.
>
> On Thu, Jan 7, 2016 at 7:40 PM, Roman Shtykh  
> 
> wrote:
>
>
> Igniters,
>
> I noticed Javadoc link on https://apacheignite.readme.io/ points to the
> older 'b1' version, instead of 
> 'final'https://ignite.apache.org/releases/1.5.0.final/javadoc/
>
> -Roman
>
>
>
>

[jira] [Created] (IGNITE-2346) Rework java code generation of DataSource

[Alexey Kuznetsov (JIRA)]

Alexey Kuznetsov created IGNITE-2346:


 Summary: Rework java code generation of DataSource
 Key: IGNITE-2346
 URL: https://issues.apache.org/jira/browse/IGNITE-2346
 Project: Ignite
  Issue Type: Sub-task
  Components: wizards
Affects Versions: 1.5
Reporter: Alexey Kuznetsov
Assignee: Alexey Kuznetsov
 Fix For: 1.6


Current code generation create datasource for each cache.
This should be refactored to single method that should be reused.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

RE: IgniteBinary, POJOs and indexing

[Andrey Kornev]

Sergi,

Thanks for your reply.

I didn't quite get the point about the "persistent configuration storage". 
Could you please elaborate? 

>From my point of view, dynamic index management requires something similar to 
>the SQL DDL, like create/drop index, alter index, etc. So in addition to the 
>indexing metadata in the cache config, Ignite could provide an index 
>management API: create, drop, alter, describe. It would be up to the user to 
>ensure that the indexes get recreated after the cluster is restarted.

Such approach is no different from the way Ignite currently handles dynamically 
created caches -- there is no "persistent configuration storage" to store the 
dynamic cache configs, and Ignite doesn't even try to recreate them after a 
full cluster restart -- it's the use who does that, either in the code or thru 
the configuration files.

Thanks
Andrey

> From: sergi.vlady...@gmail.com
> Date: Sat, 9 Jan 2016 13:10:13 +0300
> Subject: Re: IgniteBinary, POJOs and indexing
> To: dev@ignite.apache.org
> 
> I don't think we can easily implement this feature. Because it means that
> we need some kind of "persistent configuration storage", which will be
> consistent in all the scenarios of failures/restarts. So we have to design
> this thing first keeping in mind that in the future we will store there not
> only "dynamic indexes" but some other dynamic configuration as well.
> 
> I don't think I will be able to work on it myself but since it is going to
> be a general mechanism mostly unrelated to SQL we can ask someone else to
> pick it up.
> 
> Sergi
> 
> 
> 2016-01-08 21:20 GMT+03:00 Dmitriy Setrakyan :
> 
> > Hi Andrey,
> >
> > The answer right now is simple. Yes, you can create classes and add fields
> > at runtime. No, you cannot change indexes that you have created in cache
> > configuration.
> >
> > However, you are raising a very valid point. We should be able to create
> > and update indexes dynamically.  There is a ticket, IGNITE-735 [1], that
> > has been sitting around for a while. I think we should reprioritize it.
> >
> > Sergi, can you please comment on how hard this would be to implement?
> >
> > [1] https://issues.apache.org/jira/browse/IGNITE-735
> >
> > On Fri, Jan 8, 2016 at 9:02 AM, Andrey Kornev 
> > wrote:
> >
> > > Hello, Ignite Community,
> > >
> > > IgniteBinary javadocs mention the ability to dynamically change the
> > > structure of the "classes" without restarting the cluster. The javadocs
> > > even say that the new fields become automatically available to the SQL
> > > queries with no extra effort. It's all fine and dandy, but how can I tell
> > > Ignite that some of the new fields should also be indexed?
> > >
> > > Using the example from the same javadocs, my binary object initially has
> > > two field A and B. I configure the cache entry metadata to index the
> > field
> > > A and then create the cache. When later I change the structure by adding
> > a
> > > new field C, how can I tell Ignite that I now want only fields B and C to
> > > be included in the index?
> > >
> > > Related to above,  is there any way to modify the indexes after the cache
> > > has been started? In this case I do not modify the structure of the
> > class,
> > > but rather change which fields get indexed, the sorting properties, etc.
> > >
> > > Finally, how about introducing new POJO classes at runtime (yes, I can do
> > > it -- I run in OSGi environment)? For example, at the cache creation time
> > > the cache metadata only had the POJOA class annotated to index its field
> > > "foo", and then later the user introduces a new POJOB class annotated to
> > > index its field "bar". Would POJOB start getting indexed automatically,
> > or
> > > the user will be given the finger?
> > >
> > > Any input will be very much appreciated!
> > > Andrey
> > >
> >