+1
On Tue, Nov 24, 2020 at 10:24 AM Pavel Tupitsyn
wrote:
> +1
>
> On Tue, Nov 24, 2020 at 3:25 AM Saikat Maitra
> wrote:
>
> > +1
> >
> > On Mon, Nov 23, 2020 at 4:55 PM Valentin Kulichenko <
> > valentin.kuliche...@gmail.com> wrote:
> >
> > > +1
> > >
> > > On Mon, Nov 23, 2020 at 2:44 PM Den
+1
2020-11-24 11:33 GMT+03:00, Anton Vinogradov :
> +1
>
> On Tue, Nov 24, 2020 at 10:24 AM Pavel Tupitsyn
> wrote:
>
>> +1
>>
>> On Tue, Nov 24, 2020 at 3:25 AM Saikat Maitra
>> wrote:
>>
>> > +1
>> >
>> > On Mon, Nov 23, 2020 at 4:55 PM Valentin Kulichenko <
>> > valentin.kuliche...@gmail.com>
Denis,
Good point. Both serializers use reflection API.
However, we will allow users to configure static schema along with 'strict'
schema mode, we still need to validate user classes on client nodes against
the latest schema in the grid and reflection API is the only way to do it.
One can find a
-1
I think the compute APIs are an important part of Ignite’s value. Calling it a
database diminishes that in my opinion.
> On 24 Nov 2020, at 08:40, Ivan Pavlukhin wrote:
>
> +1
>
> 2020-11-24 11:33 GMT+03:00, Anton Vinogradov :
>> +1
>>
>> On Tue, Nov 24, 2020 at 10:24 AM Pavel Tupitsyn
>
],
discPort=47502, order=66, intOrder=35, lastExchangeTime=1606212165542,
loc=false, ver=2.10.0#20201124-sha1:, isClient=false], topVer=67,
msgTemplate=null,
span=org.apache.ignite.internal.processors.tracing.NoopSpan@73893b7d,
nodeId8=30b8d2de, msg=Node left, type=NODE_LEFT, tstamp
Igniters,
I think we should support unsigned data types:
uByte, uShort, uInt, uLong
Java does not have them, but many other languages do,
and with the growing number of thin clients this is important.
For example, in current Ignite.NET implementation we store unsigned values
as signed internally
Andrey Mashenkov created IGNITE-13748:
-
Summary: Schema configuration public API
Key: IGNITE-13748
URL: https://issues.apache.org/jira/browse/IGNITE-13748
Project: Ignite
Issue Type: Sub-
Pavel,
I totally support that. Also, if we are aiming for
stronger platform-independance,
in our schemas we may want to support bit-notation (int32, uint64)? For
example
"long" can mean a different type on different platforms and it's easy to
confuse
them (happens often when using ODBC for example
Agree, let's get rid of "long, short, byte" in the protocol definition.
We can use Rust style, which is concise and unambiguous:
i8, u8, i16, u16, etc
On Tue, Nov 24, 2020 at 1:58 PM Igor Sapego wrote:
> Pavel,
>
> I totally support that. Also, if we are aiming for
> stronger platform-independa
Thanks, Pavel and Igor.
I like your ideas to have i8 or int8 instead of Integer.
But the naming doesn't address the issue.
I agree internal types should be portable across different systems with and
without unsigned type support.
The only issue here is that unsigned types cover different ranges.
Andrey Mashenkov created IGNITE-13749:
-
Summary: Annotation-based schema generator.
Key: IGNITE-13749
URL: https://issues.apache.org/jira/browse/IGNITE-13749
Project: Ignite
Issue Type: I
Andrey Mashenkov created IGNITE-13750:
-
Summary: Unsinged types support.
Key: IGNITE-13750
URL: https://issues.apache.org/jira/browse/IGNITE-13750
Project: Ignite
Issue Type: Improvement
Andrey,
I think it is much simpler:
- Add protocol support for those types (basically, just add more type ids)
- Treat uLong as long in Java (bitwise representation is the same)
ANSI SQL does not have unsigned integers, so we can simply say that
unsigned value relative comparison is not supported
Andrey Mashenkov created IGNITE-13751:
-
Summary: Add maven plugins to new repo.
Key: IGNITE-13751
URL: https://issues.apache.org/jira/browse/IGNITE-13751
Project: Ignite
Issue Type: Impro
Let's add maven plugins for sanity checks at the early stage.
I've created a ticket for this [1].
Also, I've found initial pom.xml has a target version Java 8.
Do we intend to move to Java 11 (or may be next LTS) and drop Java 8 in
Ignite 3.0?
[1] https://issues.apache.org/jira/browse/IGNITE-137
Actually, I think it is not so hard to implement comparison of unsigned
numbers in
SQL even in Java, so it does not seem to be a big issue from my perspective.
Now to the usage of unsigned types from Java - I think, if a user uses
unsigned type
in a schema and is going to interact with it from Jav
Java 15 is better, VarHandles, ForeignMemory access and so on.
In both cases, I support the Java version 11 and higher for the development!
вт, 24 нояб. 2020 г. в 15:21, Andrey Mashenkov :
> Let's add maven plugins for sanity checks at the early stage.
> I've created a ticket for this [1].
>
>
Pavel,
If you are ok with narrowing range for unsigned types then we could add a
constraint for unsigned types on schema level (like nullability flag)
and treat them as signed types in storage.
We are going with a separate storage type-system and binary protocol
type-system, however most of type
Andrey,
I don't think range narrowing is a good idea.
Do you see any problems with the simple approach I described?
On Tue, Nov 24, 2020 at 4:01 PM Andrey Mashenkov
wrote:
> Pavel,
>
> If you are ok with narrowing range for unsigned types then we could add a
> constraint for unsigned types on
Andrey Mashenkov created IGNITE-13752:
-
Summary: Schema evolution converters.
Key: IGNITE-13752
URL: https://issues.apache.org/jira/browse/IGNITE-13752
Project: Ignite
Issue Type: Improve
Pavel,
- Treat uLong as long in Java (bitwise representation is the same)
That way is impossible.
Assume, you have a .NET class with a uByte field and map it to 'uint8'
column.
Then you set the field value to "250" and put the object into a table,
field value perfectly fits to a single byte 'int
> That way is impossible.
That is how it works in Ignite since the beginning with .NET and C++ :)
You can use unsigned primitives as cache keys and values, as fields and
properties,
and in SQL queries (even in WHERE x=y clauses) - it works transparently for
the users.
Java side knows nothing and t
Alexey Goncharuk created IGNITE-13753:
-
Summary: Non-thread-safe collection is used for the list of
registered MBeans in JmxMetricExporterSpi
Key: IGNITE-13753
URL: https://issues.apache.org/jira/browse/IGNITE
Pavel,
I believe uLong values beyond 2^63 can't be treated correctly for now
(WHERE x > y may return wrong results)
I think we could make "true" support for unsigned types, but they will have
limitations on the Java side.
Thus, the one will not be able to map uint64 to Java long primitive, but to
Folks, I think this is a reasonable request. I thought about this when I
was drafting the IEP, but hesitated to add these types right away.
> That is how it works in Ignite since the beginning with .NET and C++ :)
I have some doubts that it actually works as expected, it needs some
checking (will
> SQL range queries it will break
> WHERE x > y may return wrong results
Yes, range queries, inequality comparisons and so on are broken
for unsigned data types, I think I mentioned this somewhere above.
Again, in my opinion, we can document that SQL is not supported on those
types,
end of story.
Actually, we can support comparisons in 3.0: once we the actual type
information, we can make proper runtime adjustments and conversions to
treat those values as unsigned - it will be just a bit more expensive.
вт, 24 нояб. 2020 г. в 18:32, Pavel Tupitsyn :
> > SQL range queries it will break
> >
Jave15 looks awesome.
* Hidden classes [1] can be used by codegenerators.
* Records [2] can replace boilerplate code like IgniteBiTuple, GridTupleX.
[1] https://openjdk.java.net/jeps/371
[2] https://openjdk.java.net/jeps/384
On Tue, Nov 24, 2020 at 3:38 PM Alexey Zinoviev
wrote:
> Java 15 is b
If we use Java15 for development, can the resulting package be used from a
Java11 app (the latest LTS)?
On Tue, Nov 24, 2020 at 7:51 PM Andrey Mashenkov
wrote:
> Jave15 looks awesome.
>
> * Hidden classes [1] can be used by codegenerators.
> * Records [2] can replace boilerplate code like Ignite
Hi Igniters,
I've detected some new issue on TeamCity to be handled. You are more than
welcomed to help.
If your changes can lead to this failure(s): We're grateful that you were a
volunteer to make the contribution to this project, but things change and you
may no longer be able to finalize
Ilya, Anton, Ivan, hi!
I fix some comments you leave in the PR. Also I checked some test suites
and found that some tests are written in the core module but depend on the
indexing module (or other modules). Some of such test classes contain tests
that are related to the core functionality, but som
Andrey,
Understood, thanks. Agree with the idea of creating a task for GraalVM
support. Just want to be sure there won't be any fundamental limitations in
the new serialization protocol that will make it hard or impossible to
generate native images. Probably, we should specify the requirements - a
Hi Igniters,
I've detected some new issue on TeamCity to be handled. You are more than
welcomed to help.
If your changes can lead to this failure(s): We're grateful that you were a
volunteer to make the contribution to this project, but things change and you
may no longer be able to finalize
Pavel Tupitsyn created IGNITE-13754:
---
Summary: .NET: LINQ provider emits incorrect table alias for
queries with JOIN and GROUP BY combined
Key: IGNITE-13754
URL: https://issues.apache.org/jira/browse/IGNITE-1375
Pavel Tupitsyn created IGNITE-13755:
---
Summary: .NET: Inspections fail after TC upgrade - unused classes
detected
Key: IGNITE-13755
URL: https://issues.apache.org/jira/browse/IGNITE-13755
Project: Ig
35 matches
Mail list logo
