Alexey Goncharuk created IGNITE-5061:
Summary: Add ability to enable and disable rebalancing per-node
Key: IGNITE-5061
URL: https://issues.apache.org/jira/browse/IGNITE-5061
Project: Ignite
Roman,
Is it possible to define a kind of property in Redis connection string (or
property map) for this purpose? IMO ideally we should "externalize" cache
name somehow, so that it can be changed with no changes to user's code.
Alex,
Not sure if this is a good idea as you will end up with PARTITIO
Crosspost to dev list.
Igniters,
This proposal looks quite reasonable. Do we have any restrictions that
could prevent implementing such feature?
I think it's nice to have in Ignite.
Thanks!
-Dmitry.
On Sun, Apr 23, 2017 at 1:37 AM, npordash wrote:
> Thanks!
>
> That would definitely help addr
Alexey,
Thank you for sharing the idea.
"REDIS_CACHE" can be specified in xml or programmatically (as in your example).
If not, Ignite will behave in the same way when a cache the user intends to use
is not created (I think it will produce an error or warning).I.e. it is a
normal cache a user en
Alexander Belyak created IGNITE-5062:
Summary: Support new parameters in .Net
Key: IGNITE-5062
URL: https://issues.apache.org/jira/browse/IGNITE-5062
Project: Ignite
Issue Type: Bug
Vladimir Ozerov created IGNITE-5063:
---
Summary: Dynamic cache start hangs in validation fails
Key: IGNITE-5063
URL: https://issues.apache.org/jira/browse/IGNITE-5063
Project: Ignite
Issue Ty
Done. I'm going to refactor code appropriately then.
Best Regards,
Igor
On Sat, Apr 22, 2017 at 2:37 AM, Denis Magda wrote:
> +1 for the discontinuation. Igor, please update C++ readme doc once this
> feature is implemented. I think it’s still fine to claim that Windows XP,
> Vista are supporte
Github user devozerov closed the pull request at:
https://github.com/apache/ignite/pull/1861
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is
Sergey Chugunov created IGNITE-5064:
---
Summary: Obsolete EventTypes to be removed
Key: IGNITE-5064
URL: https://issues.apache.org/jira/browse/IGNITE-5064
Project: Ignite
Issue Type: Task
Vladimir,
Probably we may set the cache name via
https://redis.io/commands/client-setname, save it and use until the user
specifies another name.
#That will be the name for the default cache (mainly for STRING data). For
other data types, like hashes (https://redis.io/topics/data-types), I am
t
> Pasha, what’s about .NET? Do we still support these ancient Windows
versions or the doc has to be altered as well?
Ignite.NET depends on Ignite C++, so we have to drop XP support there as
well.
On Mon, Apr 24, 2017 at 12:23 PM, Igor Sapego wrote:
> Done. I'm going to refactor code appropriate
Yury Babak created IGNITE-5065:
--
Summary: DSL/scription support
Key: IGNITE-5065
URL: https://issues.apache.org/jira/browse/IGNITE-5065
Project: Ignite
Issue Type: New Feature
Componen
Pavel Tupitsyn created IGNITE-5066:
--
Summary: .NET: Continuous query fails with exception on Java side
Key: IGNITE-5066
URL: https://issues.apache.org/jira/browse/IGNITE-5066
Project: Ignite
User want to contribute to project, but seems he has no rights in JIRA to
track a ticket.
See comments to ticket IGNITE-5046 [1].
Please, would someone handle this?
[1] https://issues.apache.org/jira/browse/IGNITE-5046
--
Best regards,
Andrey V. Mashenkov
Igniters,
Currently we have limited support of binary enums. The main problem is that
we do not store any metadata about enum names. For this reason it is
impossible to use enums in SQL even though H2 already supports it [1]. We
need to improve enum metadata support and provide some additional API
Done.
On Mon, Apr 24, 2017 at 3:16 PM, Andrey Mashenkov <
andrey.mashen...@gmail.com> wrote:
> User want to contribute to project, but seems he has no rights in JIRA to
> track a ticket.
> See comments to ticket IGNITE-5046 [1].
>
> Please, would someone handle this?
>
>
> [1] https://issues.apac
Vladimir,
I am very confused. I thought we already had resolved this issue in this
ticket:
https://issues.apache.org/jira/browse/IGNITE-3595
Can you clarify?
D.
On Mon, Apr 24, 2017 at 5:58 AM, Vladimir Ozerov
wrote:
> Igniters,
>
> Currently we have limited support of binary enums. The main
Sorry, looks like I mismanaged tickets in JIRA. In fact, we implemented H2
part, but Ignite's part is not ready yet and is managed in IGNITE-4575 [1].
Ticket you mentioned was an umbrella.
[1] https://issues.apache.org/jira/browse/IGNITE-4575
On Mon, Apr 24, 2017 at 4:28 PM, Dmitriy Setrakyan
wr
Dear Igniters,
Seems we have almost the same issue with Memcached protocol.
There is an ability to define a cache name via operation extras message
part (
https://github.com/memcached/memcached/wiki/BinaryProtocolRevamped#packet-structure)
but it looks a bit complicated from my point of view...
Vladimir,
I would really like to avoid special registration of Enums. Can you find a
way to handle it automatically?
D.
On Mon, Apr 24, 2017 at 6:33 AM, Vladimir Ozerov
wrote:
> Sorry, looks like I mismanaged tickets in JIRA. In fact, we implemented H2
> part, but Ignite's part is not ready ye
Sure. It would be great!
--
View this message in context:
http://apache-ignite-developers.2346864.n4.nabble.com/Ignite-ML-next-steps-IGNITE-5029-tp17096p17135.html
Sent from the Apache Ignite Developers mailing list archive at Nabble.com.
Can we just use the name "default" in such cases?
On Mon, Apr 24, 2017 at 6:33 AM, Seliverstov Igor
wrote:
> Dear Igniters,
>
> Seems we have almost the same issue with Memcached protocol.
>
> There is an ability to define a cache name via operation extras message
> part (
> https://github.com/m
Roman,
Why can't we use just some kind of mapping to bind Redis database ID to
cache name and define it via xml or programmatically?
In this case 0 database will be mapped to a default cache, so that we won't
break abstraction in Redis terms.
Regards,
Igor
2017-04-24 12:43 GMT+03:00 Roman Shtyk
Sergey Chugunov created IGNITE-5067:
---
Summary: Absolute swapFilePath for MemoryPolicy is merged
incorrectly with working dir path
Key: IGNITE-5067
URL: https://issues.apache.org/jira/browse/IGNITE-5067
Igniters,
[long read, take a cup of coffee]
Historically every SQL in Ignite must be executed against particular cache:
SqlQuery requires cache, JDBC and ODBC drivers require cache name. This
works fine until we add CREATE TABLE. Consider an empty cluster - how do
you connect to it if you have no
Ilya Lantukh created IGNITE-5068:
Summary: Redesign usage of GridDhtPartitionTopologyImpl.part2node
map to store only diff from affinity assignment
Key: IGNITE-5068
URL: https://issues.apache.org/jira/browse/IGNIT
Dima,
No. It is normal (and inevitably) practice to register enums before they
are used.
This is how enum is created in MySQL:
CREATE TABLE shirts (
name VARCHAR(40),
size ENUM('x-small', 'small', 'medium', 'large', 'x-large')
);
And in PostgreSQL:
CREATE TYPE mood AS ENUM ('sad', 'ok'
I agree with Dmitriy, it is preferable to have this enum registration
optional. It will be a better user experience.
Why do we "inevitably" need it?
Sergi
2017-04-24 17:02 GMT+03:00 Vladimir Ozerov :
> Dima,
>
> No. It is normal (and inevitably) practice to register enums before they
> are used
Yes, we need to move on making Ignite work as any usual SQL db.
But please avoid mixing all this stuff together, lets have a separate task
(and discussion if needed) for each item in your list.
Sergi
2017-04-24 16:58 GMT+03:00 Vladimir Ozerov :
> Igniters,
>
> [long read, take a cup of coffee]
GitHub user tledkov-gridgain opened a pull request:
https://github.com/apache/ignite/pull/1863
IGNITE-5036 Disallow @QuerySqlField and @QueryTextField on methods
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain/apache-ig
Github user isapego closed the pull request at:
https://github.com/apache/ignite/pull/1847
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is en
Yakov Zhdanov created IGNITE-5069:
-
Summary: QueryWords example fails with exception
Key: IGNITE-5069
URL: https://issues.apache.org/jira/browse/IGNITE-5069
Project: Ignite
Issue Type: Bug
Igniters,
I have noticed quite a lot of inconsistencies with the rest of our APIs in
our new MemoryMetrics API:
1) MemoryMetrics is not a snapshot. It is a "live" instance which returns
different values each time you access some property. (IgniteCache.metrics()
returns a snapshot).
2) MemoryMetr
Igor,
I see that you are the main contributor of the ignite-cassandra-* modules.
Could you please review the changes at the ingite-cassandra-store module
for the issue IGNITE-5036.
Please take a look at the issue:
https://issues.apache.org/jira/browse/IGNITE-5036
--
Taras Ledkov
Mail-To:
Agree, looks inconsistent to me.
Alex G., could you chime in?
On Mon, Apr 24, 2017 at 6:30 PM, Pavel Tupitsyn
wrote:
> Igniters,
>
> I have noticed quite a lot of inconsistencies with the rest of our APIs in
> our new MemoryMetrics API:
>
> 1) MemoryMetrics is not a snapshot. It is a "live" ins
Igor,
What are the advantages of such mapping compared to the proposed approach?
1. From Redis perspective, we can have only 16 databases.
2. We will still have to define the cache in xml or programmatically, but make
things more complicated (a user will have to specify database n in Redis
conf
Github user skalashnikov closed the pull request at:
https://github.com/apache/ignite/pull/1727
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature
I guess the main reason to have IgniteCache returning snapshot metrics was
to collect metrics about distributed cache across the cluster.
At the same time MemoryMetrics were initially designed to be local on each
node, there were no requirements about collecting cluster-wide
MemoryMetrics.
Collect
GitHub user ilantukh opened a pull request:
https://github.com/apache/ignite/pull/1864
ignite-5068
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain/apache-ignite ignite-5068
Alternatively you can review and apply these c
GitHub user skalashnikov opened a pull request:
https://github.com/apache/ignite/pull/1865
IGNITE-3487: hidden _key and _val columns
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain/apache-ignite ignite-3487
Alternativel
Sergey, I disagree.
1) As a user, I would expect MemoryMetrics instance to be
read-only and serializable, so I can send it somewhere, store,
put into a collection and draw a graph in UI, etc.
Other metrics APIs allow this, MemoryMetrics does not.
2) Methods like enableMetrics and rateTimeInterva
Github user skalashnikov closed the pull request at:
https://github.com/apache/ignite/pull/1679
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature
Sergey,
We need to keep API consistent. If we usually return bytes, then these
metrics should return bytes as well. What is more important, when I look at
API I understand that this thing is not metrics at all. Metrics in Ignte
terms is a set of read-only numeric properties. But this interface con
It seems that all mutator methods should be simply moved to MBean interface
and change MBytes to bytes. In this case metrics interface will be
consistent.
On Mon, Apr 24, 2017 at 7:29 PM, Vladimir Ozerov
wrote:
> Sergey,
>
> We need to keep API consistent. If we usually return bytes, then these
Agree, I overlooked this during the review. However, the changes to fix
this is pretty simple - we just move all mutator methods to MBean, like
Vladimir suggested and make MBean return the live data, while the public
API will return a serializable snapshot.
Agreed?
2017-04-24 19:33 GMT+03:00 Vlad
Mauricio, thanks!
I’ve merged all your changes except the ones from CSS files. Why do we need to
change the background? Please elaborate and attach a screenshot that shows what
the changes will affect. BTW, these sort of changes have to be reviewed by
Prachi Garg.
--- css/all.css (revision 17
Denis Magda created IGNITE-5070:
---
Summary: Update Affinity Functions Documentation
Key: IGNITE-5070
URL: https://issues.apache.org/jira/browse/IGNITE-5070
Project: Ignite
Issue Type: Sub-task
Alexey Kuznetsov created IGNITE-5071:
Summary: Web Console: Support custom table names on model import
Key: IGNITE-5071
URL: https://issues.apache.org/jira/browse/IGNITE-5071
Project: Ignite
Hi guys,
Cache entries don’t store an identification of the class loader a key or value
was created with. This is why binary marshaller picks the system class loader
at deserialization time by default and you get class not found exception.
>> In general, I think ignite should try to resolve a
Hi Denis,
>> if you want to deserialize an entry then most likely you’re doing this on
>> the app side that already has the class in the class path
In this particular case the app is a deployed service and the hosting node
doesn't have the class files on its classpath. I implemented a way to depl
Igor, +1 from me.We can add a field to ConnectorConfiguration (not sure if it's
a proper place, but it's shared by REST, memcached and Redis). A user will have
to create a cache, configure as needed and specify the name in
ConnectorConfiguration.
Roman
On Monday, April 24, 2017 10:34 PM,
Github user abeliak closed the pull request at:
https://github.com/apache/ignite/pull/1862
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is en
GitHub user abeliak opened a pull request:
https://github.com/apache/ignite/pull/1866
Ignite 4799 2.0
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain/apache-ignite ignite-4799-2.0
Alternatively you can review and apply
53 matches
Mail list logo
