I have problem with Glorp and Lint. Glorp uses ilike: -message to build up queries but because there is no actual method called ilike: lint complains about it. Is this problem already solved somehow?
Hi Panu. Thanks for finding this bug. It seems a typo. Can you try chaning it to #like: instead of #ilike: and see if the test works?
thanks
mariano
On Wed, Nov 10, 2010 at 4:34 AM, Panu Suominen panu.suominen@iki.fi wrote:
I have problem with Glorp and Lint. Glorp uses ilike: -message to build up queries but because there is no actual method called ilike: lint complains about it. Is this problem already solved somehow? -- Panu _______________________________________________ SqueakDBX mailing list SqueakDBX@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/squeakdbx
2010/11/11 Mariano Martinez Peck marianopeck@gmail.com:
Hi Panu. Thanks for finding this bug. It seems a typo. Can you try chaning it to #like: instead of #ilike: and see if the test works?
But that changes semantics. readManyOf: Something where: [:a | a name like: '%bob%'] probably does not return any "Bob". However [:a | a name ilike: '%bob%'] should return.
On Thu, Nov 11, 2010 at 1:24 AM, Panu Suominen panu.suominen@iki.fi wrote:
2010/11/11 Mariano Martinez Peck marianopeck@gmail.com:
Hi Panu. Thanks for finding this bug. It seems a typo. Can you try
chaning
it to #like: instead of #ilike: and see if the test works?
But that changes semantics. readManyOf: Something where: [:a | a name like: '%bob%'] probably does not return any "Bob". However [:a | a name ilike: '%bob%'] should return.
Sorry. I was not aware of the ILIKE SQL keyboard. Seems to be used only in
PostgreSQL. And now I read the method RelationExpression >> operationFor: aSymbol
So....you are right. We should implement #ilike: similar to #like: but being case insensitive.
However, if you check #ilike: it is case insensitive too. Read the comment of method String >> match:
I am confused what we should do.
mariano
-- Panu _______________________________________________ SqueakDBX mailing list SqueakDBX@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/squeakdbx
2010/11/11 Mariano Martinez Peck marianopeck@gmail.com:
I am confused what we should do.
As a beginner I see two options. Implement #ilike: as a dummy method or change how Lint performs its cheks. First is probably much easier.
On 2010-11-10 11:35 PM, Mariano Martinez Peck wrote:
On Thu, Nov 11, 2010 at 1:24 AM, Panu Suominen <panu.suominen@iki.fi mailto:panu.suominen@iki.fi> wrote:
2010/11/11 Mariano Martinez Peck <marianopeck@gmail.com <mailto:marianopeck@gmail.com>>: > Hi Panu. Thanks for finding this bug. It seems a typo. Can you try chaning > it to #like: instead of #ilike: and see if the test works? But that changes semantics. readManyOf: Something where: [:a | a name like: '%bob%'] probably does not return any "Bob". However [:a | a name ilike: '%bob%'] should return.
Sorry. I was not aware of the ILIKE SQL keyboard. Seems to be used only in PostgreSQL. And now I read the method RelationExpression >> operationFor: aSymbol
So....you are right. We should implement #ilike: similar to #like: but being case insensitive.
However, if you check #ilike: it is case insensitive too. Read the comment of method String >> match:
I am confused what we should do.
mariano
I have an idea that whether or not LIKE is case sensitive will vary by database, so there's no way we could match that in Smalltalk. I'd be inclined to have the Smalltalk implementation of both just be case insensitive and if someone really wants a case sensitive match then they won't have exact polymorphism between the image code and the database, but they wouldn't anyway if it varies by database.
Maybe my first post was not clear enought. There is nothing wrong with the functinality of #ilike:or #like: -messages. The problem is that Lint(?) (the code style cheker) checks that there is no actual method called ilike: and reports using this message in Glorp queries as error. Of course I could just create empty method called ilike: to some class and the problem would go away. However this approach does not seem optimal and thus I was interested if someone had more sophisticated solution.
You could create one that actually did something. That's what I was assuming. There's already a like: method there for both that purpose and so that you can write blocks that operate both as queries and as blocks.
On 2010-11-11 3:26 PM, Panu Suominen wrote:
Maybe my first post was not clear enought. There is nothing wrong with the functinality of #ilike:or #like: -messages. The problem is that Lint(?) (the code style cheker) checks that there is no actual method called ilike: and reports using this message in Glorp queries as error. Of course I could just create empty method called ilike: to some class and the problem would go away. However this approach does not seem optimal and thus I was interested if someone had more sophisticated solution.
I created following method to the String class. Change set is attached. Squeak source was down so I was not able to make a commit with monticello.
String>>ilike: wildcardString " 'ABCDE' ilike: 'abc%' " ^(wildcardString copyReplaceAll: '%' with: '*') asLowercase match: self asLowercase.
I think this should take care of the problem.
Hi Panu. The thing is that like is not case sensitive neither.
Look:
'abcde' like: 'abc%' true 'aBcde' like: 'abc%' true 'abcde' like: 'aBc%' true
'abcde' ilike: 'abc%' true 'aBcde' ilike: 'abc%' true 'abcde' ilike: 'aBc%' true
Can you provide testcases to show the problem? or the differences between like and ilike
thanks
mariano
On Fri, Nov 19, 2010 at 8:26 AM, Panu Suominen panu.suominen@iki.fi wrote:
I created following method to the String class. Change set is attached. Squeak source was down so I was not able to make a commit with monticello.
String>>ilike: wildcardString " 'ABCDE' ilike: 'abc%' " ^(wildcardString copyReplaceAll: '%' with: '*') asLowercase match: self asLowercase.
I think this should take care of the problem.
-- Panu
SqueakDBX mailing list SqueakDBX@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/squeakdbx
On Thu, Nov 11, 2010 at 9:04 PM, Alan Knight knight@acm.org wrote:
On 2010-11-10 11:35 PM, Mariano Martinez Peck wrote:
On Thu, Nov 11, 2010 at 1:24 AM, Panu Suominen panu.suominen@iki.fiwrote:
2010/11/11 Mariano Martinez Peck marianopeck@gmail.com:
Hi Panu. Thanks for finding this bug. It seems a typo. Can you try
chaning
it to #like: instead of #ilike: and see if the test works?
But that changes semantics. readManyOf: Something where: [:a | a name like: '%bob%'] probably does not return any "Bob". However [:a | a name ilike: '%bob%'] should return.
Sorry. I was not aware of the ILIKE SQL keyboard. Seems to be used only
in PostgreSQL. And now I read the method RelationExpression >> operationFor: aSymbol
So....you are right. We should implement #ilike: similar to #like: but being case insensitive.
However, if you check #ilike: it is case insensitive too. Read the comment of method String >> match:
I am confused what we should do.
mariano
I have an idea that whether or not LIKE is case sensitive will vary by database, so there's no way we could match that in Smalltalk. I'd be inclined to have the Smalltalk implementation of both just be case insensitive and if someone really wants a case sensitive match then they won't have exact polymorphism between the image code and the database, but they wouldn't anyway if it varies by database. ç
Alan: I agree, the problem is that right now, it is mapped to #ilike: wich doesn't exist in Pharo. So....we need to implement #ilike: or change the mapping to other method.
-- Alan Knight [|], Engineering Manager, Cincom Smalltalkknight@acm.orgaknight@cincom.comhttp://www.cincom.com/smalltalk
SqueakDBX mailing list SqueakDBX@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/squeakdbx
Yes, I think creating ilike: is the easiest solution.
On 2010-11-19 12:08 PM, Mariano Martinez Peck wrote:
On Thu, Nov 11, 2010 at 9:04 PM, Alan Knight <knight@acm.org mailto:knight@acm.org> wrote:
On 2010-11-10 11:35 PM, Mariano Martinez Peck wrote:
On Thu, Nov 11, 2010 at 1:24 AM, Panu Suominen <panu.suominen@iki.fi <mailto:panu.suominen@iki.fi>> wrote: 2010/11/11 Mariano Martinez Peck <marianopeck@gmail.com <mailto:marianopeck@gmail.com>>: > Hi Panu. Thanks for finding this bug. It seems a typo. Can you try chaning > it to #like: instead of #ilike: and see if the test works? But that changes semantics. readManyOf: Something where: [:a | a name like: '%bob%'] probably does not return any "Bob". However [:a | a name ilike: '%bob%'] should return. Sorry. I was not aware of the ILIKE SQL keyboard. Seems to be used only in PostgreSQL. And now I read the method RelationExpression >> operationFor: aSymbol So....you are right. We should implement #ilike: similar to #like: but being case insensitive. However, if you check #ilike: it is case insensitive too. Read the comment of method String >> match: I am confused what we should do. mariano
I have an idea that whether or not LIKE is case sensitive will vary by database, so there's no way we could match that in Smalltalk. I'd be inclined to have the Smalltalk implementation of both just be case insensitive and if someone really wants a case sensitive match then they won't have exact polymorphism between the image code and the database, but they wouldn't anyway if it varies by database. ç
Alan: I agree, the problem is that right now, it is mapped to #ilike: wich doesn't exist in Pharo. So....we need to implement #ilike: or change the mapping to other method.
-- Alan Knight [|], Engineering Manager, Cincom Smalltalk knight@acm.org <mailto:knight@acm.org> aknight@cincom.com <mailto:aknight@cincom.com> http://www.cincom.com/smalltalk _______________________________________________ SqueakDBX mailing list SqueakDBX@lists.squeakfoundation.org <mailto:SqueakDBX@lists.squeakfoundation.org> http://lists.squeakfoundation.org/mailman/listinfo/squeakdbx
Hi panu. If you dbms is case sencitive in like, you can implement a FunctionExpression and extend your Database Platform. Some thing like upper(field) like %upper(param)%
Best Regards
Enviado desde mi BlackBerry® de Claro Argentina
-----Original Message----- From: Panu Suominen panu.suominen@iki.fi Sender: squeakdbx-bounces@lists.squeakfoundation.org Date: Thu, 11 Nov 2010 06:24:28 To: The complete and open-source solution to relational database accesssqueakdbx@lists.squeakfoundation.org Reply-To: The complete and open-source solution to relational database access squeakdbx@lists.squeakfoundation.org Subject: Re: [SqueakDBX] Link complains about ilike:
2010/11/11 Mariano Martinez Peck marianopeck@gmail.com:
Hi Panu. Thanks for finding this bug. It seems a typo. Can you try chaning it to #like: instead of #ilike: and see if the test works?
But that changes semantics. readManyOf: Something where: [:a | a name like: '%bob%'] probably does not return any "Bob". However [:a | a name ilike: '%bob%'] should return.
squeakdbx@lists.squeakfoundation.org