GitHub user agoncharuk opened a pull request:
https://github.com/apache/ignite/pull/416
IGNITE-2396 - Fixed service deployment on cache creation.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/agoncharuk/ignite ignite-2396
Alte
GitHub user ptupitsyn opened a pull request:
https://github.com/apache/ignite/pull/417
IGNITE-2380 .NET: Allow Ignite configuration in app.config and web.config
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/ptupitsyn/ignite ign
I have just noticed another question on dev list - whether it is possible
to index of objects that are maps' values and maps, in turn, act as cache
values. This is another point to consider, before taking any decision here.
One more.. What if collection of objects to index act as cache value?
>Fr
Yakov,
I absolutely agree that the idea of trying to support any bullshit that
comes to users mind is wrong and harmful.
Indexing of a collection when this collection is a cache value looks
useless to me, it is a bad domain model design, we should discourage this.
Indexing a map cache values is
Hey guys,
Please bear with me as I am relatively new to Ignite. But here’s my thoughts:
I have to agree that we can’t jump in an go build anything that comes to mind
but to Sergi’s point about indexing collection objects being pointless I would
take for instance the example of a car dealership
Semen Boikov created IGNITE-2433:
Summary: Internal cache type inconsistency for IGFS caches
Key: IGNITE-2433
URL: https://issues.apache.org/jira/browse/IGNITE-2433
Project: Ignite
Issue Type
Alexey Goncharuk created IGNITE-2434:
Summary: Ignite updates cache store even if EntryProcessor did not
update cache entry
Key: IGNITE-2434
URL: https://issues.apache.org/jira/browse/IGNITE-2434
GitHub user agoncharuk opened a pull request:
https://github.com/apache/ignite/pull/418
IGNITE-2434 - Do not update cache store if entry processor was a noop.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/agoncharuk/ignite igni
I agree that dynamic indexing at runtime is certainly useful.
I don't think persistent storage or supporting removing and updating of
indexes added at runtime is necessary - i think its more frequent use case
to be able to add than remove or update.
--
View this message in context:
http://ap
Hey Christos!
I've actually agreed with Dmitriy's proposal (which covers the use case
you've described but with another SQL syntax). It will not require too much
efforts to implement, will not have too complex config, will have clear
performance characteristics. This absolutely makes sense.
But f
GitHub user ashutakGG opened a pull request:
https://github.com/apache/ignite/pull/419
Ignite-2191 Experiment (not to merge)
https://issues.apache.org/jira/browse/IGNITE-2191
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/ashutak
Ah ok, I get it.
Yes in that sense you are absolutely right, that would be nonsense.
C.
On Fri, Jan 22, 2016 at 2:16 PM, Sergi Vladykin
wrote:
> Hey Christos!
>
> I've actually agreed with Dmitriy's proposal (which covers the use case
> you've described but with another SQL syntax). It will no
Igniters,
I'm working on LINQ support in Ignite.NET ([1]).
For the uninitiated, LINQ will allow cache SQL queries in a strongly-typed
way, which is awesome:
cache.ToQueryable().Where(person => person.Age > 20)
instead of
cache.Query(new SqlQuery(typeof(Person), "age > ?", 20))
To greatly sim
Nikolay Tikhonov created IGNITE-2435:
Summary: Mesos doesn't work with limited access to internet
Key: IGNITE-2435
URL: https://issues.apache.org/jira/browse/IGNITE-2435
Project: Ignite
I
Denis Magda created IGNITE-2436:
---
Summary: GridCacheWriteBehindStore flushes a single value when the
queue size is reached
Key: IGNITE-2436
URL: https://issues.apache.org/jira/browse/IGNITE-2436
Project
Github user asfgit closed the pull request at:
https://github.com/apache/ignite/pull/3
---
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 enable
Dmitriy,
I think I got your point. I still have BinaryNameMapper and BinaryIdMapper
interfaces, but I have now by one implementation for each mapper with
properties as you wrote before.
- BinaryBaseNameMapper - an implementation of BinaryNameMapper that has
*setSimpleName(boolean isSImpleName)* pr
Github user asfgit closed the pull request at:
https://github.com/apache/ignite/pull/418
---
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 enab
Looks cool to me.
Sergi
2016-01-22 18:04 GMT+03:00 Pavel Tupitsyn :
> Igniters,
>
> I'm working on LINQ support in Ignite.NET ([1]).
>
> For the uninitiated, LINQ will allow cache SQL queries in a strongly-typed
> way, which is awesome:
> cache.ToQueryable().Where(person => person.Age > 20)
>
Hi Wei Jiang,
I would better review your current approach to have better understanding
on what you're trying to implement.
Please share the code. If it's the same as being discussed in "about AOP
development" thread that let me know, I'll take a look there.
--
Denis
On 1/22/2016 10:28 AM,
Another issue: JIRA has release 1.5, however to my knowledge the project had
at least
1.5.0-b1
1.5.0.final
Which one JIRA's version is related to?
Cos
On Thu, Jan 21, 2016 at 05:33AM, Konstantin Boudnik wrote:
> There might be a way to enforce it on the JIRA side, I just have no idea,
Konstantin Boudnik created IGNITE-2437:
--
Summary: Zeppelin interperet doesn't import external dependencies
Key: IGNITE-2437
URL: https://issues.apache.org/jira/browse/IGNITE-2437
Project: Ignite
Why do we need 2 mappers vs 1? What is the difference between them?
On Fri, Jan 22, 2016 at 9:46 AM, Artem Shutak wrote:
> Dmitriy,
>
> I think I got your point. I still have BinaryNameMapper and BinaryIdMapper
> interfaces, but I have now by one implementation for each mapper with
> properties
I would say 1.5.0.final (the beta did not include all the fixes).
On Fri, Jan 22, 2016 at 5:26 PM, Konstantin Boudnik wrote:
> Another issue: JIRA has release 1.5, however to my knowledge the project
> had
> at least
> 1.5.0-b1
> 1.5.0.final
>
> Which one JIRA's version is related to?
>
Looks nice, but what is ToQueryable() method for? Is the cache initially
not queryable? :)
-Val
On Fri, Jan 22, 2016 at 9:49 AM, Sergi Vladykin
wrote:
> Looks cool to me.
>
> Sergi
>
> 2016-01-22 18:04 GMT+03:00 Pavel Tupitsyn :
>
> > Igniters,
> >
> > I'm working on LINQ support in Ignite.NET
25 matches
Mail list logo
