On Tue, Feb 24, 2015 at 5:17 PM, Ivan Gürtler <ivan.gurtler(a)ahead-itec.com > wrote: > Hi, > > we use aerogear with oracle ... when AG used parameter with length longer > than 4000 ... for example in table INSTALLATION and parameter DEVICETOKEN > ... or in master branch ... table IOSVARIANT and parameter CERT_DATA .. it > becomes problem because oracle has Varchar2 with max length 4000 and when > parameter is longer it needs LOB ... > > We changed in table INSTALLATION parameter DEVICETOKEN as VARCHAR2(4000) > ... it is temporary solution .. but in IOSVARIANT parameter CERT_DATA has > length 100000 and it is too large. In version 1.0.x certificate was LOB and > it was ok for oracle. > > Object with large length as CERT_DATA makes it impossible to support > oracle. Is it possible to keep database schema the way it would support > oracle??? Or do you have any idea how to support oracle with current schema? > Ok, on last release (1.0.2) is was a byte array: * https://github.com/aerogear/aerogear-unifiedpush-server/blob/1.0.2/model/... * https://github.com/aerogear/aerogear-unifiedpush-server/blob/1.0.2/model/... but yeah, in this branch it's a string: * https://github.com/qmx/aerogear-unified-push-server/blob/certificate_data... * https://github.com/qmx/aerogear-unified-push-server/blob/certificate_data... I think there was a Postgres bug that lead us to that implementation: https://issues.jboss.org/browse/AGPUSH-1144 But now, since causes some fun on the ORCL side of things ;-( Greetings > > Thanks for help ... > > > *Mgr. Ivan Gürtler* > Mobile software developer > > AHEAD iTec, s.r.o., Botanická 554/68a, > 602 00 Brno (Czech Republic) > > www.ahead-itec.com | twitter <https://www.twitter.com/AHEADiTec> | > mobile security solutions > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf

yes, here it is ... https://issues.jboss.org/browse/AGPUSH-1297 .. is ok ? *Mgr. Ivan Gürtler* Mobile software developer AHEAD iTec, s.r.o., Botanická 554/68a, 602 00 Brno (Czech Republic) www.ahead-itec.com | twitter <https://www.twitter.com/AHEADiTec> | mobile security solutions 2015-02-24 17:33 GMT+01:00 Matthias Wessendorf <matzew(a)apache.org&gt;: > Ivan, btw. can you create a JIRA ticket for this as well ? > > Thanks for all the valuable feedback from you guys > > On Tue, Feb 24, 2015 at 5:29 PM, Matthias Wessendorf <matzew(a)apache.org&gt; > wrote: > >> >> >> On Tue, Feb 24, 2015 at 5:17 PM, Ivan Gürtler < >> ivan.gurtler(a)ahead-itec.com&gt; wrote: >> >>> Hi, >>> >>> we use aerogear with oracle ... when AG used parameter with length >>> longer than 4000 ... for example in table INSTALLATION and parameter >>> DEVICETOKEN ... or in master branch ... table IOSVARIANT and parameter >>> CERT_DATA .. it becomes problem because oracle has Varchar2 with max length >>> 4000 and when parameter is longer it needs LOB ... >>> >>> We changed in table INSTALLATION parameter DEVICETOKEN as >>> VARCHAR2(4000) ... it is temporary solution .. but in IOSVARIANT parameter >>> CERT_DATA has length 100000 and it is too large. In version 1.0.x >>> certificate was LOB and it was ok for oracle. >>> >>> Object with large length as CERT_DATA makes it impossible to support >>> oracle. Is it possible to keep database schema the way it would support >>> oracle??? Or do you have any idea how to support oracle with current schema? >>> >> >> Ok, on last release (1.0.2) is was a byte array: >> * >> https://github.com/aerogear/aerogear-unifiedpush-server/blob/1.0.2/model/... >> * >> https://github.com/aerogear/aerogear-unifiedpush-server/blob/1.0.2/model/... >> >> but yeah, in this branch it's a string: >> * >> https://github.com/qmx/aerogear-unified-push-server/blob/certificate_data... >> * >> https://github.com/qmx/aerogear-unified-push-server/blob/certificate_data... >> >> I think there was a Postgres bug that lead us to that implementation: >> https://issues.jboss.org/browse/AGPUSH-1144 >> >> But now, since causes some fun on the ORCL side of things ;-( >> >> Greetings >> >> >>> >>> Thanks for help ... >>> >>> >>> *Mgr. Ivan Gürtler* >>> Mobile software developer >>> >>> AHEAD iTec, s.r.o., Botanická 554/68a, >>> 602 00 Brno (Czech Republic) >>> >>> www.ahead-itec.com | twitter <https://www.twitter.com/AHEADiTec> | >>> mobile security solutions >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >> >> >> >> -- >> Matthias Wessendorf >> >> blog: http://matthiaswessendorf.wordpress.com/ >> sessions: http://www.slideshare.net/mwessendorf >> twitter: http://twitter.com/mwessendorf >> > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev