Ranges support

[Alotor]

Grails doesn't allow you to map directly IntRange and ObjectRange and ignores them! I couldn't find why it does this.

The only solution i could think of is to wrap the ranges in a custom type.

@lmivan check it out and let me know

[coveralls]

Coverage decreased (-1.77%) when pulling 09d1848068f13f692d363ecdf589cb9603f0a085 on ranges_support into 6b9218a969c0add2e5587f0da9c6a4bff1e6df43 on master.

[ilopmar]

Great work!

I'll try to check it tonight or tomorrow.

[ilopmar]

I've revised the changes and I think they're great! :+1: I've rebased origin/master, cleaned up the imports and add a new commit to add seconds to the timestamp string format.

What about tstzrange? In the dialect there's a commented line with this type and also in RangeType there's a constant for TIMESTAMP_TZ_RANGE. Does it work? I need to do some searchs when I get a stable internet connection but I've doing some tests with bound and unbound lower and upper ranges and I think is weird:

select int4range(0,100,'()');
 int4range 
-----------
 [1,100)

select numrange(0,100,'()');
 numrange 
----------
 (0,100)

select int4range(0,100,'[]');
 int4range 
-----------
 [0,101)

select numrange(0,100,'[]');
 numrange 
----------
 [0,100]

As you can see, if I use numrange the ranges are created propertly but if I use int4range there're not. If tried to use numrange during the inserts but I cann't cast numrange to int4range. I think we should research more on this to be able to define ranges with different lower and upper bounds.

Do you want to change something or should I merge this into master?

[coveralls]

Coverage decreased (-1.77%) when pulling 6bb8498dbdd05f0628d218f8729523edf4d4caf2 on ranges_support into 6b9218a969c0add2e5587f0da9c6a4bff1e6df43 on master.

[Alotor]

About the the tstzrange I want to make it available when we have tested the ranges more. I wanted to have a version with "easier" types.

About the range functions. I think they are ok be. What do you mean that they don't work? I think we can safely merge into master to have the new type support but we can wait to create a version whe I can implement the criterias.

[ilopmar]

I think the problem is that you can only define this ranges: [) in a table if you use int4range but the other ranges: (), (] and [] can't be defined.

On the other hand if you use numrange you can define the four ranges. I think it should be possible to define the four ranges in a domain class.

Sent from my Nexus 10 El 27/07/2014 21:23, "Alonso Torres" notifications@github.com escribió:

About the the tstzrange I want to make it available when we have tested the ranges more. I wanted to have a version with "easier" types.

About the range functions. I think they are ok be. What do you mean that they don't work? I think we can safely merge into master to have the new type support but we can wait to create a version whe I can implement the criterias.

— Reply to this email directly or view it on GitHub https://github.com/kaleidos/grails-postgresql-extensions/pull/44#issuecomment-50282890 .

[Alotor]

No, that's not it.

What happens is that for integers [0,100] = (-1, 100] = [0, 101) so postgres prefers to store it on the last form (always as [) )

For "general numbers" the property [0,100] is not always equal to [0,101) that's why it's storing it on the same format as stored.

---

Alonso Javier Torres

On Mon, Jul 28, 2014 at 11:11 AM, Iván López notifications@github.com wrote:

I think the problem is that you can only define this ranges: [) in a table if you use int4range but the other ranges: (), (] and [] can't be defined.

On the other hand if you use numrange you can define the four ranges. I think it should be possible to define the four ranges in a domain class.

Sent from my Nexus 10 El 27/07/2014 21:23, "Alonso Torres" notifications@github.com escribió:

About the the tstzrange I want to make it available when we have tested the ranges more. I wanted to have a version with "easier" types.

About the range functions. I think they are ok be. What do you mean that they don't work? I think we can safely merge into master to have the new type support but we can wait to create a version whe I can implement the criterias.

— Reply to this email directly or view it on GitHub < https://github.com/kaleidos/grails-postgresql-extensions/pull/44#issuecomment-50282890>

.

— Reply to this email directly or view it on GitHub https://github.com/kaleidos/grails-postgresql-extensions/pull/44#issuecomment-50315296 .

[coveralls]

Coverage decreased (-1.79%) when pulling f9a579d4746264b488a94f1fab46b09f81cc7f42 on ranges_support into cc40563364516f4300a0b3cf4ee7093bfe9ef672 on master.

[coveralls]

Coverage decreased (-1.8%) when pulling e31a244a385039d928bd823df9dd4264811b49e9 on ranges_support into bbc1cb4a79b1356efd4b913f57cbc7c9bc1871e3 on master.

[bryce-gibson]

I was just wondering whether there's anything outstanding with this PR? :-)

It would be great functionality to have available :-)

[ilopmar]

We were waiting for the new Grails 2.4.4 because it includes a bugfix that allows us to remove a wrapper object that we've created. I think @Alotor will change this in the following weeks :-P

[Alotor]

Yeah I'll try to wrap this ASAP.

[bryce-gibson]

Awesome :-)

Just wanted to check it hadn't been forgotten :-)

Thanks for the awesome plugin :-D