[GitHub] ignite pull request: ignite-1717 Portable marshaller fixed for cas...

[agura]

GitHub user agura opened a pull request:

https://github.com/apache/ignite/pull/180

ignite-1717 Portable marshaller fixed for cases when serialization proxy 
should be serialized by optimized marshaller



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/agura/incubator-ignite ignite-1717

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/180.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #180


commit 7be9d50ec08e737c1ba01397c2bd9769ddf7766f
Author: agura 
Date:   2015-10-20T14:36:45Z

ignite-1717 Portable marshaller fixed for cases when serialization proxy 
should be serialized by optimized marshaller

commit 78c85c9ee99e03360a0e813b3fb639ddbe48d078
Author: agura 
Date:   2015-10-22T15:31:38Z

ignite-1717 Portable marshaller fixed for cases when serialization proxy 
should be serialized by optimized marshaller

commit 85baf4e9c96c74efbe3f2361a7ff08a136bd488d
Author: agura 
Date:   2015-10-27T11:31:24Z

ignite-1717 Portable marshaller fixed for cases when serialization proxy 
should be serialized by optimized marshaller




---
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 enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Regrouping of streamers under TeamCity

[Raul Kripalani]

Hello all,

I've regrouped Ignite streamer modules in TeamCity into the existing Ignite
Streamers build configuration. Thus, the separate Ignite JMS and Ignite
MQTT have disappeared.

I faced some troubles with the ActiveMQ KahaDB file locks in TeamCity,
hence my commits today in that module, as I could not reproduce the error
locally. It's now fixed.

Regards,

*Raúl Kripalani*
PMC & Committer @ Apache Ignite, Apache Camel | Integration, Big Data and
Messaging Engineer
http://about.me/raulkripalani | http://www.linkedin.com/in/raulkripalani
http://blog.raulkr.net | twitter: @raulvk

[GitHub] ignite pull request: ignite-1717 Portable marshaller fixed for cas...

[agura]

Github user agura closed the pull request at:

https://github.com/apache/ignite/pull/169


---
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 enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Created] (IGNITE-1801) Warning message printing out in wrong place

[Pavel Konstantinov (JIRA)]

Pavel Konstantinov created IGNITE-1801:
--

 Summary: Warning message printing out in wrong place
 Key: IGNITE-1801
 URL: https://issues.apache.org/jira/browse/IGNITE-1801
 Project: Ignite
  Issue Type: Sub-task
Reporter: Pavel Konstantinov


Currently we printing out th warning message "Charts do not support Explain and 
Scan query" in the header panel. But in this case we hide all the other UI 
controls and user cannot switch result in another view. He MUST repeat SCAN 
command - this is very uncomfortable.



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

Re: Portables hash code.

[Alexey Kuznetsov]

Igniters,

After some thinking on hash code generation for portables and POJO store we
could do the following:

1) As Dmitriy suggested in [1] a boolean flag "isHashCode" to
JdbcTypeField. If true then this field will be used for hash code
calculation by pojo store.
2) Add to all PortableBuilder.setField() methods one more boolean argument
isHashCode.
3) PortableBuilder should store fields in order they were added.
4) PortableBuilder will calculate hash code if at least one field was added
with this flag.
   I think we could use algorithm like this (pseudocode):
int hashCode = 0;

for (field : fields) {
if (field.isHashCode)
hashCode = 31 * hashCode + (field.value != null
? field.value.hashCode() : 0);
}
.
5) Describe in documentation that ORDER of fields is VERY IMPORTANT for
hash code calculation and equality checks.

Thoughs?

[1]
https://cwiki.apache.org/confluence/display/IGNITE/Jdbc+Store+Configuration

On Wed, Oct 28, 2015 at 1:06 PM, Alexey Kuznetsov 
wrote:

> Denis,
>
> My use case:
>
> In my legacy database I have table Organization with compound ID: (sbjID;
> orgID).
> For Pojo store will be generated key with 2 fields inside:
> OrganizationKey(int sbjID; int orgID).
>
> And store will load this key into cache.
>
> Of course usual scenario will be when key is primitive (int or long), but
> portable also could be a key.
>
> And one more case: several types in same cache: for store we should have
> different key types.
>
>
> On Wed, Oct 28, 2015 at 12:58 PM, Denis Magda  wrote:
>
>> Sure, makes sense to add a documentation section to PortableObject
>> describing default implementation of hashCode/equals.
>>
>> However, I don’t see any significant reason why the end user needs to use
>> portable objects as keys.
>>
>> —
>> Denis
>>
>> > On 28 окт. 2015 г., at 7:42, Alexey Kuznetsov 
>> wrote:
>> >
>> > Dmitriy,
>> >
>> >>> How about we check that dashcode is not 0 when storing portable keys
>> in
>> > cache?
>> >
>> > And print warning in log? Sounds good for me.
>> >
>> > -
>> >
>> > But I will try to describe once again my concern.
>> >
>> > I'm don't know anything about portables. So, I open javadoc and see some
>> > idiomatic code like this:
>> >
>> > builder = ...
>> >
>> > for ( fileds) {
>> >  builder.setField(..)
>> > }
>> >
>> > portable = builder.build();
>> >
>> > And I in my PojoStore I do as described.
>> >
>> > If there was a NOTE in javadoc about hashCode() it will save 4 hours of
>> > debug for me :)
>> >
>> >
>> >
>> >
>> > On Wed, Oct 28, 2015 at 11:32 AM, Dmitriy Setrakyan <
>> dsetrak...@apache.org>
>> > wrote:
>> >
>> >> How about we check that dashcode is not 0 when storing portable keys in
>> >> cache?
>> >>
>> >> On Tue, Oct 27, 2015 at 8:42 PM, Alexey Kuznetsov <
>> akuznet...@gridgain.com
>> >>>
>> >> wrote:
>> >>
>> >>> Andrey, thanks.
>> >>>
>> >>> Actually I use this not well documented method to solve my problem.
>> >>>
>> >>> And I'm proposed to at least add more info for PortableBuilder about
>> this
>> >>> method.
>> >>>
>> >>> On Wed, Oct 28, 2015 at 10:19 AM, Andrey Kornev <
>> >> andrewkor...@hotmail.com>
>> >>> wrote:
>> >>>
>>  Alexey,
>> 
>>  PortableBuilder has an (un-documented) method hashCode(int hashCode)
>> >> that
>>  should be used to explicitly set the hashCode for the portable
>> instance
>>  being built. I'm not sure why this has been designed this way, but
>> I'm
>>  guessing that since the PortableBuilder is pretty dumb and it
>> wouldn't
>> >>> know
>>  which fields to use for hash code computation (in some cases you'd
>> only
>>  want to include specific portable fields rather than all fields).
>> 
>>  Regards
>>  Andrey
>> 
>> > Date: Wed, 28 Oct 2015 09:49:07 +0700
>> > Subject: Portables hash code.
>> > From: akuznet...@gridgain.com
>> > To: dev@ignite.apache.org
>> >
>> > Igniters,
>> >
>> > I'm working on  [1] "IGNITE-1753 Rework CacheJdbcPojoStore to new
>> >> API."
>> >
>> > And one of subtasks is to support portable objects with JDBC store.
>> >
>> > I implemented this and during tests found a huge performance drop
>> >> when
>> >>> I
>> > have PortableObject as key.
>> >
>> > After some debugging I found that all my portable objects have
>> >> hashCode
>>  = 0.
>> > I'm using PortableBuilder to build my portable objects.
>> >
>> > And I expected that PortableBuilder will calculate proper hash code
>> >> for
>>  me
>> > out of the box.
>> >
>> > I think we should at least describe in PortableBuilder javadocs that
>> >> by
>> > default PortableBuilder will return zero hashcode?
>> >
>> > Or we should calculate hashcode in PortableBuilder.build() method?
>> >
>> > Or may be we could add boolean argument
>> 

Re: Portables hash code.

[Vladimir Ozerov]

I do not like idea of predefined alogrithms, because we will lack
flexibility. What if user has backing Java/.Net class where hash code is
calculated differently? What if user *cannot change* this class for some
reason?
Any hard-coded hash code algorithm looks like a shortcut for me.

Moreover, hash code can be different on different paltforms for the same
base type. E.g. in Java hash code of string is more or less constant, while
in .Net it changes from release to release. Java UUID has one hash code,
.Net counterpart Guid has another hash code. Etc.. As a result user will be
able to use this solution without any problems only if he operates on
primitive types.

Why not abstracting out this to some interface and provide default
implementation with proposed algorithm?

On Wed, Oct 28, 2015 at 5:49 PM, Alexey Kuznetsov 
wrote:

> Igniters,
>
> After some thinking on hash code generation for portables and POJO store we
> could do the following:
>
> 1) As Dmitriy suggested in [1] a boolean flag "isHashCode" to
> JdbcTypeField. If true then this field will be used for hash code
> calculation by pojo store.
> 2) Add to all PortableBuilder.setField() methods one more boolean argument
> isHashCode.
> 3) PortableBuilder should store fields in order they were added.
> 4) PortableBuilder will calculate hash code if at least one field was added
> with this flag.
>I think we could use algorithm like this (pseudocode):
> int hashCode = 0;
>
> for (field : fields) {
> if (field.isHashCode)
> hashCode = 31 * hashCode + (field.value != null
> ? field.value.hashCode() : 0);
> }
> .
> 5) Describe in documentation that ORDER of fields is VERY IMPORTANT for
> hash code calculation and equality checks.
>
> Thoughs?
>
> [1]
> https://cwiki.apache.org/confluence/display/IGNITE/Jdbc+Store+Configuration
>
> On Wed, Oct 28, 2015 at 1:06 PM, Alexey Kuznetsov  >
> wrote:
>
> > Denis,
> >
> > My use case:
> >
> > In my legacy database I have table Organization with compound ID: (sbjID;
> > orgID).
> > For Pojo store will be generated key with 2 fields inside:
> > OrganizationKey(int sbjID; int orgID).
> >
> > And store will load this key into cache.
> >
> > Of course usual scenario will be when key is primitive (int or long), but
> > portable also could be a key.
> >
> > And one more case: several types in same cache: for store we should have
> > different key types.
> >
> >
> > On Wed, Oct 28, 2015 at 12:58 PM, Denis Magda 
> wrote:
> >
> >> Sure, makes sense to add a documentation section to PortableObject
> >> describing default implementation of hashCode/equals.
> >>
> >> However, I don’t see any significant reason why the end user needs to
> use
> >> portable objects as keys.
> >>
> >> —
> >> Denis
> >>
> >> > On 28 окт. 2015 г., at 7:42, Alexey Kuznetsov <
> akuznet...@gridgain.com>
> >> wrote:
> >> >
> >> > Dmitriy,
> >> >
> >> >>> How about we check that dashcode is not 0 when storing portable keys
> >> in
> >> > cache?
> >> >
> >> > And print warning in log? Sounds good for me.
> >> >
> >> > -
> >> >
> >> > But I will try to describe once again my concern.
> >> >
> >> > I'm don't know anything about portables. So, I open javadoc and see
> some
> >> > idiomatic code like this:
> >> >
> >> > builder = ...
> >> >
> >> > for ( fileds) {
> >> >  builder.setField(..)
> >> > }
> >> >
> >> > portable = builder.build();
> >> >
> >> > And I in my PojoStore I do as described.
> >> >
> >> > If there was a NOTE in javadoc about hashCode() it will save 4 hours
> of
> >> > debug for me :)
> >> >
> >> >
> >> >
> >> >
> >> > On Wed, Oct 28, 2015 at 11:32 AM, Dmitriy Setrakyan <
> >> dsetrak...@apache.org>
> >> > wrote:
> >> >
> >> >> How about we check that dashcode is not 0 when storing portable keys
> in
> >> >> cache?
> >> >>
> >> >> On Tue, Oct 27, 2015 at 8:42 PM, Alexey Kuznetsov <
> >> akuznet...@gridgain.com
> >> >>>
> >> >> wrote:
> >> >>
> >> >>> Andrey, thanks.
> >> >>>
> >> >>> Actually I use this not well documented method to solve my problem.
> >> >>>
> >> >>> And I'm proposed to at least add more info for PortableBuilder about
> >> this
> >> >>> method.
> >> >>>
> >> >>> On Wed, Oct 28, 2015 at 10:19 AM, Andrey Kornev <
> >> >> andrewkor...@hotmail.com>
> >> >>> wrote:
> >> >>>
> >>  Alexey,
> >> 
> >>  PortableBuilder has an (un-documented) method hashCode(int
> hashCode)
> >> >> that
> >>  should be used to explicitly set the hashCode for the portable
> >> instance
> >>  being built. I'm not sure why this has been designed this way, but
> >> I'm
> >>  guessing that since the PortableBuilder is pretty dumb and it
> >> wouldn't
> >> >>> know
> >>  which fields to use for hash code computation (in some cases you'd
> >> only
> >>  want to include specific portable fields rather than all fields).
> >> 
> >>  Regards
> >>  

[jira] [Created] (IGNITE-1803) Optimize random portable field lookup.

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-1803:
---

 Summary: Optimize random portable field lookup.
 Key: IGNITE-1803
 URL: https://issues.apache.org/jira/browse/IGNITE-1803
 Project: Ignite
  Issue Type: Task
  Components: general
Affects Versions: ignite-1.4
Reporter: Vladimir Ozerov
Assignee: Vladimir Ozerov
Priority: Critical
 Fix For: 1.5


This ticket should be implemented after IGNITE-1770 is ready because it relies 
on constant-time lookup feature availability.

The following optimizations should be performed:
1) Create method "PortableFieldReader createFieldReader()" on PortableObject 
interface. This will minimize garbage and let us get rid from unnecessary 
header parsing.

2) Field position is calculated as follows: 
- Lookup ID mapper for type, get ID;
- Lookup schemas for type;
- Lookup schema for schema ID;
- Lookup field offset for field ID inside schema.
4 (!!!) map lookups! It should work as follows:
- Lookup ID mapper and schemas for type;
- Lookup field offset using (schema ID + field ID).
The latter lookup should be performed from highly optimized long->int map, not 
from conventional HashMap.

3) Normal field scan is faster than constant-time lookup when amount of fields 
is about 10. We need to have two field search strategies and pick the most 
performant one based on field count (which can be derived in advance from 
object footer size).



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

Re: Portables hash code.

[Alexey Kuznetsov]

Denis,

My use case:

In my legacy database I have table Organization with compound ID: (sbjID;
orgID).
For Pojo store will be generated key with 2 fields inside:
OrganizationKey(int sbjID; int orgID).

And store will load this key into cache.

Of course usual scenario will be when key is primitive (int or long), but
portable also could be a key.

And one more case: several types in same cache: for store we should have
different key types.


On Wed, Oct 28, 2015 at 12:58 PM, Denis Magda  wrote:

> Sure, makes sense to add a documentation section to PortableObject
> describing default implementation of hashCode/equals.
>
> However, I don’t see any significant reason why the end user needs to use
> portable objects as keys.
>
> —
> Denis
>
> > On 28 окт. 2015 г., at 7:42, Alexey Kuznetsov 
> wrote:
> >
> > Dmitriy,
> >
> >>> How about we check that dashcode is not 0 when storing portable keys in
> > cache?
> >
> > And print warning in log? Sounds good for me.
> >
> > -
> >
> > But I will try to describe once again my concern.
> >
> > I'm don't know anything about portables. So, I open javadoc and see some
> > idiomatic code like this:
> >
> > builder = ...
> >
> > for ( fileds) {
> >  builder.setField(..)
> > }
> >
> > portable = builder.build();
> >
> > And I in my PojoStore I do as described.
> >
> > If there was a NOTE in javadoc about hashCode() it will save 4 hours of
> > debug for me :)
> >
> >
> >
> >
> > On Wed, Oct 28, 2015 at 11:32 AM, Dmitriy Setrakyan <
> dsetrak...@apache.org>
> > wrote:
> >
> >> How about we check that dashcode is not 0 when storing portable keys in
> >> cache?
> >>
> >> On Tue, Oct 27, 2015 at 8:42 PM, Alexey Kuznetsov <
> akuznet...@gridgain.com
> >>>
> >> wrote:
> >>
> >>> Andrey, thanks.
> >>>
> >>> Actually I use this not well documented method to solve my problem.
> >>>
> >>> And I'm proposed to at least add more info for PortableBuilder about
> this
> >>> method.
> >>>
> >>> On Wed, Oct 28, 2015 at 10:19 AM, Andrey Kornev <
> >> andrewkor...@hotmail.com>
> >>> wrote:
> >>>
>  Alexey,
> 
>  PortableBuilder has an (un-documented) method hashCode(int hashCode)
> >> that
>  should be used to explicitly set the hashCode for the portable
> instance
>  being built. I'm not sure why this has been designed this way, but I'm
>  guessing that since the PortableBuilder is pretty dumb and it wouldn't
> >>> know
>  which fields to use for hash code computation (in some cases you'd
> only
>  want to include specific portable fields rather than all fields).
> 
>  Regards
>  Andrey
> 
> > Date: Wed, 28 Oct 2015 09:49:07 +0700
> > Subject: Portables hash code.
> > From: akuznet...@gridgain.com
> > To: dev@ignite.apache.org
> >
> > Igniters,
> >
> > I'm working on  [1] "IGNITE-1753 Rework CacheJdbcPojoStore to new
> >> API."
> >
> > And one of subtasks is to support portable objects with JDBC store.
> >
> > I implemented this and during tests found a huge performance drop
> >> when
> >>> I
> > have PortableObject as key.
> >
> > After some debugging I found that all my portable objects have
> >> hashCode
>  = 0.
> > I'm using PortableBuilder to build my portable objects.
> >
> > And I expected that PortableBuilder will calculate proper hash code
> >> for
>  me
> > out of the box.
> >
> > I think we should at least describe in PortableBuilder javadocs that
> >> by
> > default PortableBuilder will return zero hashcode?
> >
> > Or we should calculate hashcode in PortableBuilder.build() method?
> >
> > Or may be we could add boolean argument PortableBuilder.build(boolean
> > generateHashCode)?
> >
> > Thoughts?
> >
> > P.S. After I added manual hashcode calculation to my
> >> CacheJdbcPojoStore
> > performance drop is gone away.
> >
> >
> > [1] https://issues.apache.org/jira/browse/IGNITE-1753
> > --
> > Alexey Kuznetsov
> > GridGain Systems
> > www.gridgain.com
> 
> 
> >>>
> >>>
> >>>
> >>> --
> >>> Alexey Kuznetsov
> >>> GridGain Systems
> >>> www.gridgain.com
> >>>
> >>
> >
> >
> >
> > --
> > Alexey Kuznetsov
> > GridGain Systems
> > www.gridgain.com
>
>


-- 
Alexey Kuznetsov
GridGain Systems
www.gridgain.com

[jira] [Created] (IGNITE-1800) Annotation MBeanServerResource should be deleted as unsupported.

[Artem Shutak (JIRA)]

Artem Shutak created IGNITE-1800:


 Summary: Annotation MBeanServerResource should be deleted as 
unsupported.
 Key: IGNITE-1800
 URL: https://issues.apache.org/jira/browse/IGNITE-1800
 Project: Ignite
  Issue Type: Task
Affects Versions: ignite-1.4
Reporter: Artem Shutak


Ignite has MBeanServerResource annotation, but there is no code which process 
the annotation. Looks like support of MBeanServerResource annotation has been 
deleted, but the annotation was not deleted by mistake.

It should be Deprecated or deleted.



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

Re: Web Console - Load metadata from database

[Prachi Garg]

I see. What about the tables being selected? Can we have them cleared when the 
popup launches?

-P


> On Oct 28, 2015, at 7:49 PM, Alexey Kuznetsov  wrote:
> 
> Prach,
> 
> Thanks for typos. I fixed them.
> 
> Let's discuss issue about  load metadata popup.
> 
> I have a lot of experience with databases admin tools and it was very
> painful
> when some tool does not save settings that I entered in previous session.
> 
> So, I implemented saving previous values in metadata popup.
> 
> And I (personally) think that we do not need reset button for just 3 fields
> (URL/User/password).
> 
> 
>> On Thu, Oct 29, 2015 at 6:08 AM, Prachi Garg  wrote:
>> 
>> Hey guys,
>> 
>> When I try to load metadata from the database, the fields in the popup
>> contain values that were previously used to load the metadata. For example,
>> the JDBC url and username fields already have values I had entered
>> previously, and the tables previously selected for loading the metadata are
>> shown selected every time a new popup is launched.
>> We should either have a reset button to clear the previous values, or the
>> popup should come up with clear fields every time.
>> I've created a ticket - https://issues.apache.org/jira/browse/IGNITE-1805
>> 
>> I've also added some comments to
>> https://issues.apache.org/jira/browse/IGNITE-843 regarding some typos on
>> the web console. Please take a look.
>> 
>> Thanks,
>> -Prachi
> 
> 
> 
> -- 
> Alexey Kuznetsov
> GridGain Systems
> www.gridgain.com

Re: Web Console - Load metadata from database

[Dmitriy Setrakyan]

On Wed, Oct 28, 2015 at 9:23 PM, Alexey Kuznetsov 
wrote:

> Prachi,
>
> From my experience users usually like to click "Next -> Next -> Next ->
> OK".
> I don't think it is a good idea to force user to see error message "No
> tables selected" if he/she just clicks as described above.
> Does it make sense for you?
>

Alexey, I don’t think I agree. Some values, like JDBC driver, are pretty
hard to revert to previous values without a reset button.


>
> On Thu, Oct 29, 2015 at 10:14 AM, Prachi Garg  wrote:
>
> > I see. What about the tables being selected? Can we have them cleared
> when
> > the popup launches?
> >
> > -P
> >
> >
> > > On Oct 28, 2015, at 7:49 PM, Alexey Kuznetsov  >
> > wrote:
> > >
> > > Prach,
> > >
> > > Thanks for typos. I fixed them.
> > >
> > > Let's discuss issue about  load metadata popup.
> > >
> > > I have a lot of experience with databases admin tools and it was very
> > > painful
> > > when some tool does not save settings that I entered in previous
> session.
> > >
> > > So, I implemented saving previous values in metadata popup.
> > >
> > > And I (personally) think that we do not need reset button for just 3
> > fields
> > > (URL/User/password).
> > >
> > >
> > >> On Thu, Oct 29, 2015 at 6:08 AM, Prachi Garg 
> > wrote:
> > >>
> > >> Hey guys,
> > >>
> > >> When I try to load metadata from the database, the fields in the popup
> > >> contain values that were previously used to load the metadata. For
> > example,
> > >> the JDBC url and username fields already have values I had entered
> > >> previously, and the tables previously selected for loading the
> metadata
> > are
> > >> shown selected every time a new popup is launched.
> > >> We should either have a reset button to clear the previous values, or
> > the
> > >> popup should come up with clear fields every time.
> > >> I've created a ticket -
> > https://issues.apache.org/jira/browse/IGNITE-1805
> > >>
> > >> I've also added some comments to
> > >> https://issues.apache.org/jira/browse/IGNITE-843 regarding some typos
> > on
> > >> the web console. Please take a look.
> > >>
> > >> Thanks,
> > >> -Prachi
> > >
> > >
> > >
> > > --
> > > Alexey Kuznetsov
> > > GridGain Systems
> > > www.gridgain.com
> >
>
>
>
> --
> Alexey Kuznetsov
> GridGain Systems
> www.gridgain.com
>

[jira] [Created] (IGNITE-1806) Rework UI and code generation to new query configuration

[Vasiliy Sisko (JIRA)]

Vasiliy Sisko created IGNITE-1806:
-

 Summary: Rework UI and code generation to new query configuration
 Key: IGNITE-1806
 URL: https://issues.apache.org/jira/browse/IGNITE-1806
 Project: Ignite
  Issue Type: Bug
  Components: UI
Affects Versions: 1.5
Reporter: Vasiliy Sisko
Assignee: Vasiliy Sisko
 Fix For: 1.5


New query configuration is being implemented in ignite-950-new branch.
Web Console should correspond to new implementation.



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

Re: Portables hash code.

[Dmitriy Setrakyan]

On Wed, Oct 28, 2015 at 8:12 AM, Vladimir Ozerov 
wrote:

> I do not like idea of predefined alogrithms, because we will lack
> flexibility. What if user has backing Java/.Net class where hash code is
> calculated differently? What if user *cannot change* this class for some
> reason?
> Any hard-coded hash code algorithm looks like a shortcut for me.
>
> Moreover, hash code can be different on different paltforms for the same
> base type. E.g. in Java hash code of string is more or less constant, while
> in .Net it changes from release to release. Java UUID has one hash code,
> .Net counterpart Guid has another hash code. Etc.. As a result user will be
> able to use this solution without any problems only if he operates on
> primitive types.
>
> Why not abstracting out this to some interface and provide default
> implementation with proposed algorithm?
>

How about adding JdbcTypeHasher interface, which will look like this:

interface JdbcTypeHasher {
public int hashCode(IgniteObject o, Collection fields);
}

User should be optionally set this interface at the JdbcType level. If not
set, then we use our default implementation.

Will this work?



>
> On Wed, Oct 28, 2015 at 5:49 PM, Alexey Kuznetsov  >
> wrote:
>
> > Igniters,
> >
> > After some thinking on hash code generation for portables and POJO store
> we
> > could do the following:
> >
> > 1) As Dmitriy suggested in [1] a boolean flag "isHashCode" to
> > JdbcTypeField. If true then this field will be used for hash code
> > calculation by pojo store.
> > 2) Add to all PortableBuilder.setField() methods one more boolean
> argument
> > isHashCode.
> > 3) PortableBuilder should store fields in order they were added.
> > 4) PortableBuilder will calculate hash code if at least one field was
> added
> > with this flag.
> >I think we could use algorithm like this (pseudocode):
> > int hashCode = 0;
> >
> > for (field : fields) {
> > if (field.isHashCode)
> > hashCode = 31 * hashCode + (field.value != null
> > ? field.value.hashCode() : 0);
> > }
> > .
> > 5) Describe in documentation that ORDER of fields is VERY IMPORTANT for
> > hash code calculation and equality checks.
> >
> > Thoughs?
> >
> > [1]
> >
> https://cwiki.apache.org/confluence/display/IGNITE/Jdbc+Store+Configuration
> >
> > On Wed, Oct 28, 2015 at 1:06 PM, Alexey Kuznetsov <
> akuznet...@gridgain.com
> > >
> > wrote:
> >
> > > Denis,
> > >
> > > My use case:
> > >
> > > In my legacy database I have table Organization with compound ID:
> (sbjID;
> > > orgID).
> > > For Pojo store will be generated key with 2 fields inside:
> > > OrganizationKey(int sbjID; int orgID).
> > >
> > > And store will load this key into cache.
> > >
> > > Of course usual scenario will be when key is primitive (int or long),
> but
> > > portable also could be a key.
> > >
> > > And one more case: several types in same cache: for store we should
> have
> > > different key types.
> > >
> > >
> > > On Wed, Oct 28, 2015 at 12:58 PM, Denis Magda 
> > wrote:
> > >
> > >> Sure, makes sense to add a documentation section to PortableObject
> > >> describing default implementation of hashCode/equals.
> > >>
> > >> However, I don’t see any significant reason why the end user needs to
> > use
> > >> portable objects as keys.
> > >>
> > >> —
> > >> Denis
> > >>
> > >> > On 28 окт. 2015 г., at 7:42, Alexey Kuznetsov <
> > akuznet...@gridgain.com>
> > >> wrote:
> > >> >
> > >> > Dmitriy,
> > >> >
> > >> >>> How about we check that dashcode is not 0 when storing portable
> keys
> > >> in
> > >> > cache?
> > >> >
> > >> > And print warning in log? Sounds good for me.
> > >> >
> > >> > -
> > >> >
> > >> > But I will try to describe once again my concern.
> > >> >
> > >> > I'm don't know anything about portables. So, I open javadoc and see
> > some
> > >> > idiomatic code like this:
> > >> >
> > >> > builder = ...
> > >> >
> > >> > for ( fileds) {
> > >> >  builder.setField(..)
> > >> > }
> > >> >
> > >> > portable = builder.build();
> > >> >
> > >> > And I in my PojoStore I do as described.
> > >> >
> > >> > If there was a NOTE in javadoc about hashCode() it will save 4 hours
> > of
> > >> > debug for me :)
> > >> >
> > >> >
> > >> >
> > >> >
> > >> > On Wed, Oct 28, 2015 at 11:32 AM, Dmitriy Setrakyan <
> > >> dsetrak...@apache.org>
> > >> > wrote:
> > >> >
> > >> >> How about we check that dashcode is not 0 when storing portable
> keys
> > in
> > >> >> cache?
> > >> >>
> > >> >> On Tue, Oct 27, 2015 at 8:42 PM, Alexey Kuznetsov <
> > >> akuznet...@gridgain.com
> > >> >>>
> > >> >> wrote:
> > >> >>
> > >> >>> Andrey, thanks.
> > >> >>>
> > >> >>> Actually I use this not well documented method to solve my
> problem.
> > >> >>>
> > >> >>> And I'm proposed to at least add more info for PortableBuilder
> about
> > >> this
> > >> >>> method.
> > >> >>>
> > >> >>> On Wed, 

Web Console - Load metadata from database

[Prachi Garg]

Hey guys,

When I try to load metadata from the database, the fields in the popup
contain values that were previously used to load the metadata. For example,
the JDBC url and username fields already have values I had entered
previously, and the tables previously selected for loading the metadata are
shown selected every time a new popup is launched.
We should either have a reset button to clear the previous values, or the
popup should come up with clear fields every time.
I've created a ticket - https://issues.apache.org/jira/browse/IGNITE-1805

I've also added some comments to
https://issues.apache.org/jira/browse/IGNITE-843 regarding some typos on
the web console. Please take a look.

Thanks,
-Prachi