Re: [Pharo-users] Glorp: `session login` fails for Garage SQLite

2017-08-06 Thread Herby Vojčík 

Esteban A. Maringolo wrote:

2017-08-06 8:05 GMT-03:00 Herby Vojčík:

Guillermo Polito wrote:

How did you install garage and glorp? Catalog, configurations? Can you
paste here the installation instructions you followed?


Just adding GarageGlorp as dependency:
 configuration: 'GarageGlorp' with: [ spec
 version: #stable;
 repository:



I presume this is how it should be done?


It is. [1]



In fact, from what I saw, it seems Glorp accumulated its share of technical
debt, drivers came and went, platforms, too, dialects on which it runs, too.
It seems to me it needs serious detanglement. Get rid of ifs, structure
clenly, change ifs comparing to hardcoded symbols with double dispatch, etc.


Glorp as a project accumulates technical debt because it is an old
framework, which in the last years has received maintenance in its
main trunk but is missing several refactorings and a good
re-architecture of its internals.

Also, since there wasn't an official maintenance of the ports from VW
to other languages, there are many "old" ports still around, some
work, some doesn't, but they add to the confusion. Think of Seaside
being ported several times from Pharo to, let's say, VW, and many of
those ports were abandoned for a long time.

I attach a screenshot from the latest version of Glorp in VisualWorks
8 (the main trunk), it has the same login methods as the Pharo
version.


Yeah, those probably aren't a problem (though, sometime self accessor, 
sometimes accessor), it's PharoDatabaseAccessor >> encoding which sends 
the mythical #queryEncoding.



[1] See: 
http://files.pharo.org/books-pdfs/booklet-Glorp/2017-05-02-Glorp-Spiral.pdf


Yeah, thanks, without that book I would be hardly be able to use Glorp 
at all.



Regards,

Esteban A. Maringolo

Re: [Pharo-users] Glorp: `session login` fails for Garage SQLite

2017-08-06 Thread Esteban A. Maringolo 
2017-08-06 8:05 GMT-03:00 Herby Vojčík :
> Guillermo Polito wrote:
>>
>> How did you install garage and glorp? Catalog, configurations? Can you
>> paste here the installation instructions you followed?
>
>
> Just adding GarageGlorp as dependency:
> configuration: 'GarageGlorp' with: [ spec
> version: #stable;
> repository:

> I presume this is how it should be done?

It is. [1]


> In fact, from what I saw, it seems Glorp accumulated its share of technical
> debt, drivers came and went, platforms, too, dialects on which it runs, too.
> It seems to me it needs serious detanglement. Get rid of ifs, structure
> clenly, change ifs comparing to hardcoded symbols with double dispatch, etc.

Glorp as a project accumulates technical debt because it is an old
framework, which in the last years has received maintenance in its
main trunk but is missing several refactorings and a good
re-architecture of its internals.

Also, since there wasn't an official maintenance of the ports from VW
to other languages, there are many "old" ports still around, some
work, some doesn't, but they add to the confusion. Think of Seaside
being ported several times from Pharo to, let's say, VW, and many of
those ports were abandoned for a long time.

I attach a screenshot from the latest version of Glorp in VisualWorks
8 (the main trunk), it has the same login methods as the Pharo
version.

[1] See: 
http://files.pharo.org/books-pdfs/booklet-Glorp/2017-05-02-Glorp-Spiral.pdf

Regards,

Esteban A. Maringolo

Re: [Pharo-users] Glorp: `session login` fails for Garage SQLite

2017-08-06 Thread Herby Vojčík 

Guillermo Polito wrote:

How did you install garage and glorp? Catalog, configurations? Can you
paste here the installation instructions you followed?


Just adding GarageGlorp as dependency:

baseline: spec
   
spec for: #common do: [ spec

package: 'Towergame' with: [ spec
requires: #('GarageGlorp' 'NeoJSON') ];
package: 'Towergame-Tests' with: [ spec
requires: #('Towergame' 'Mocketry') ];

configuration: 'GarageGlorp' with: [ spec
version: #stable;
repository: 
'http://smalltalkhub.com/mc/Pharo/MetaRepoForPharo60/main' ];
configuration: 'NeoJSON' with: [ spec
version: #stable;
repository: 
'http://smalltalkhub.com/mc/Pharo/MetaRepoForPharo60/main' ];
baseline: 'Mocketry' with: [ spec
repository: 'github://dionisiydk/Mocketry:v4.0.x' ];

group: 'default' with: #('Core');
group: 'development' with: #('Core' 'Tests');
group: 'Core' with: #('Towergame');
group: 'Tests' with: #('Towergame-Tests') ]

and loading it in script via

Metacello new baseline: 'Towergame'; repository: 'gitlocal:///', 
(hereRef / 'src') fullName; load: 'development'.


I presume this is how it should be done?

---

But, does that affect the presence of queryEncoding? It's the mythincal 
creature, I have browsed repos out there, history of development of 
Glorp and found it nowhere.


Did it actually exist? :-)

In fact, from what I saw, it seems Glorp accumulated its share of 
technical debt, drivers came and went, platforms, too, dialects on which 
it runs, too. It seems to me it needs serious detanglement. Get rid of 
ifs, structure clenly, change ifs comparing to hardcoded symbols with 
double dispatch, etc. :-(


Herby

P.S.: And most of all, add one smoke test to test it with each login 
type that actually uses `session login`, not database accessor's one 
(not seen, but it was mention in this thread or the one linked below no 
test actually sends `session login`).




On Sun, Aug 6, 2017 at 1:37 AM, Herby Vojčík mailto:he...@mailbox.sk>> wrote:

Herby Vojčík wrote:

Guillermo Polito wrote:

AFAIR, PharoDatabaseAccessor was meant to work with
SqueakDBX/DBXTalk
driver. No other driver should use it. At the time Garage
did not even
exist.

So I'd say that you should not use PharoDatabaseAccessor
with another
driver than the one it was originally mean to? I do not know
exactly
your setup, I was not following this thread.

Really I cannot tell much more. This was really long time ago.


Great to know!

I am not using it consciously, though. System somehow selects it and
uses it in the background (I just do MyDescriptorSystem
sessionForLogin:
myLoginObject; and before that I set GarageGlorpDrive to be the
default).

This seems to be the actual fix (make Glorp with Garage not use
PharoDatabaseAccessor).


Actually, probably not. It is more in, it should be fixed to work
with Garage. It has lots of functionality there... :-(



Herby


On Sun, Aug 6, 2017 at 12:20 AM, Herby Vojčík
mailto:he...@mailbox.sk>
>> wrote:

Esteban A. Maringolo wrote:

Herby,

I regularly use `session login`, but I don't use SQLite in
Pharo, but I
do in VisualWorks and it works just fine.
Maybe if there is a bug we should fix it. Even with a no-op
method.

Regards!

Esteban A. Maringolo


It's hard. The problem is

PharoDatabaseAccessor >> encoding
^self connection queryEncoding

which overrides parent, which is atm:

encoding
"The connection is specific to the dialect; some dialects
will need
to override this method."

^connection encoding

The former was added at GuillermoPolito.73 back in 2011 (and the
latter was the same back then). It probably fixed something,
but I
don't see any implementors of queryEncoding atm (definitely
not in
Garage). From the diff it is clear lots of databases and drivers
have gone. Now, why was it change for Pharo (and does it
need to be
changed in 2017)?

Ccing Guillermo Polito.

Herby

P.S.: I wonder how it is that no one actually had problem
with this?
This predictably fails on `session login` on pharo, unless
queryEncod

Re: [Pharo-users] Glorp: `session login` fails for Garage SQLite

2017-08-06 Thread Herby Vojčík 

Pierce Ng wrote:

On Sun, Aug 06, 2017 at 12:54:41AM +0200, Herby Vojčík wrote:

Pharo is 6.1, Glorp, Garage etc. are #stable loaded from Pharo60
catalog (see attachment).


You may want to try GlorpSQLite. Load from Catalog Browser into a fresh 60510
image. All 889 tests should pass, as has been the case since Pharo 5. In
GlorpSQLite, #encoding is implemented by UDBCDatabaseDriver.


But, Pierce, who cares about #encoding? It's #queryEncoding, sent from 
PharoDatabaseAccessor each time `session login` actually tries to do 
logging in (the bug was probably masked by the fact it just early 
returns nil if `accessor isLogged`), and missing everywhere.


Besides, as I understand, Garage is the way to go, so I want to use that 
(it works, except for bugs, which are in PharoDatabaseAccessor, not in 
Garage).



Pierce


Herby

Re: [Pharo-users] Glorp: `session login` fails for Garage SQLite

2017-08-06 Thread Pierce Ng 
On Sun, Aug 06, 2017 at 12:54:41AM +0200, Herby Vojčík wrote:
> Pharo is 6.1, Glorp, Garage etc. are #stable loaded from Pharo60
> catalog (see attachment).

You may want to try GlorpSQLite. Load from Catalog Browser into a fresh 60510
image. All 889 tests should pass, as has been the case since Pharo 5. In
GlorpSQLite, #encoding is implemented by UDBCDatabaseDriver.

Pierce

Re: [Pharo-users] Glorp: `session login` fails for Garage SQLite

2017-08-05 Thread Guillermo Polito 
How did you install garage and glorp? Catalog, configurations? Can you
paste here the installation instructions you followed?

On Sun, Aug 6, 2017 at 1:37 AM, Herby Vojčík  wrote:

> Herby Vojčík wrote:
>
>> Guillermo Polito wrote:
>>
>>> AFAIR, PharoDatabaseAccessor was meant to work with SqueakDBX/DBXTalk
>>> driver. No other driver should use it. At the time Garage did not even
>>> exist.
>>>
>>> So I'd say that you should not use PharoDatabaseAccessor with another
>>> driver than the one it was originally mean to? I do not know exactly
>>> your setup, I was not following this thread.
>>>
>>> Really I cannot tell much more. This was really long time ago.
>>>
>>
>> Great to know!
>>
>> I am not using it consciously, though. System somehow selects it and
>> uses it in the background (I just do MyDescriptorSystem sessionForLogin:
>> myLoginObject; and before that I set GarageGlorpDrive to be the default).
>>
>> This seems to be the actual fix (make Glorp with Garage not use
>> PharoDatabaseAccessor).
>>
>
> Actually, probably not. It is more in, it should be fixed to work with
> Garage. It has lots of functionality there... :-(
>
>
>
>> Herby
>>
>>
>>> On Sun, Aug 6, 2017 at 12:20 AM, Herby Vojčík >> > wrote:
>>>
>>> Esteban A. Maringolo wrote:
>>>
>>> Herby,
>>>
>>> I regularly use `session login`, but I don't use SQLite in
>>> Pharo, but I
>>> do in VisualWorks and it works just fine.
>>> Maybe if there is a bug we should fix it. Even with a no-op method.
>>>
>>> Regards!
>>>
>>> Esteban A. Maringolo
>>>
>>>
>>> It's hard. The problem is
>>>
>>> PharoDatabaseAccessor >> encoding
>>> ^self connection queryEncoding
>>>
>>> which overrides parent, which is atm:
>>>
>>> encoding
>>> "The connection is specific to the dialect; some dialects will need
>>> to override this method."
>>>
>>> ^connection encoding
>>>
>>> The former was added at GuillermoPolito.73 back in 2011 (and the
>>> latter was the same back then). It probably fixed something, but I
>>> don't see any implementors of queryEncoding atm (definitely not in
>>> Garage). From the diff it is clear lots of databases and drivers
>>> have gone. Now, why was it change for Pharo (and does it need to be
>>> changed in 2017)?
>>>
>>> Ccing Guillermo Polito.
>>>
>>> Herby
>>>
>>> P.S.: I wonder how it is that no one actually had problem with this?
>>> This predictably fails on `session login` on pharo, unless
>>> queryEncoding is somehow magically present without seeing it in
>>> source code for other platforms?
>>>
>>>
>>> 2017-08-05 15:52 GMT-03:00 Herby Vojčík >> 
>>> >>:
>>>
>>> Alistair Grant wrote:
>>>
>>> Hi Herby,
>>>
>>> On 5 August 2017 at 18:09, Herby
>>> Vojčíkmailto:he...@mailbox.sk>
>>> >> wrote:
>>>
>>> Hello!
>>>
>>> First of all, what is preferred way to (first time)
>>> login
>>> into database? I
>>> had the impression that `aDatabaseAccessor login`
>>> is sorta
>>> low-level, and
>>> one should do `session login` (after all, it is
>>> session you
>>> get to work
>>> with, not an accessor).
>>>
>>> But with Garage SQLite, `session login`, when
>>> accessor is
>>> not logged, always
>>> fails with "MessageNotUnderstood:
>>> GASqlite3Driver>>queryEncoding".
>>>
>>> Should one not use `session login` at all, then (when
>>> accessor is logged, it
>>> just does nothing, if it isn't, it connects the
>>> accessor,
>>> but tries to do
>>> some additional work which always fails)?
>>>
>>> Herby
>>>
>>>
>>> From memory this is caused by differences between
>>> VisualWorks
>>> and Pharo.
>>>
>>> Anyway, it is discussed and resolved in:
>>>
>>> http://forum.world.st/Glorp-SQLite3-issue-td4899792.html
>>> 
>>> >> >
>>>
>>>
>>> Doesn't look like solved to me. Anyway, at least I know it
>>> is known
>>> for year and no-one seemed to see it as a bug.
>>>
>>> I think it is one (you cannot just send queryEncoding where
>>> no class
>>> implements it and be fine, imo).
>>>
>>> So what is the state of `session login`? Is it meant to be
>>> used, or
>>> everyone just took a step down to low-level and uses `accessor
>>> login` instead? :-(
>>>
>>>
>>> Cheers,
>>> Alistair
>>>
>>>
>>> Thanks, Herby
>>>
>>>
>>>
>>>
>>>
>>>
>>> --
>>>
>>>
>>>
>>> Guille Polito
>>>
>>>
>>> Research Engineer
>>>
>>> French National Center for Scientific Research - _http://www.cnrs.fr_
>>>
>>>
>>>
>>> *Web:* _http://guillep.github.io_
>>>
>>> *Phone: *+33 06 52 70 66 13
>>>
>>>
>>
>>
>


-- 



Guille Polito


Research Engineer

French National Center for Scientific Research - *http://www.cnrs.fr*




*Web:* *http://guillep.github.io* 

*Phone: *+33 06 52 70 66 13

Re: [Pharo-users] Glorp: `session login` fails for Garage SQLite

2017-08-05 Thread Herby Vojčík 

Herby Vojčík wrote:

Guillermo Polito wrote:

AFAIR, PharoDatabaseAccessor was meant to work with SqueakDBX/DBXTalk
driver. No other driver should use it. At the time Garage did not even
exist.

So I'd say that you should not use PharoDatabaseAccessor with another
driver than the one it was originally mean to? I do not know exactly
your setup, I was not following this thread.

Really I cannot tell much more. This was really long time ago.


Great to know!

I am not using it consciously, though. System somehow selects it and
uses it in the background (I just do MyDescriptorSystem sessionForLogin:
myLoginObject; and before that I set GarageGlorpDrive to be the default).

This seems to be the actual fix (make Glorp with Garage not use
PharoDatabaseAccessor).


Actually, probably not. It is more in, it should be fixed to work with 
Garage. It has lots of functionality there... :-(




Herby



On Sun, Aug 6, 2017 at 12:20 AM, Herby Vojčík mailto:he...@mailbox.sk>> wrote:

Esteban A. Maringolo wrote:

Herby,

I regularly use `session login`, but I don't use SQLite in
Pharo, but I
do in VisualWorks and it works just fine.
Maybe if there is a bug we should fix it. Even with a no-op method.

Regards!

Esteban A. Maringolo


It's hard. The problem is

PharoDatabaseAccessor >> encoding
^self connection queryEncoding

which overrides parent, which is atm:

encoding
"The connection is specific to the dialect; some dialects will need
to override this method."

^connection encoding

The former was added at GuillermoPolito.73 back in 2011 (and the
latter was the same back then). It probably fixed something, but I
don't see any implementors of queryEncoding atm (definitely not in
Garage). From the diff it is clear lots of databases and drivers
have gone. Now, why was it change for Pharo (and does it need to be
changed in 2017)?

Ccing Guillermo Polito.

Herby

P.S.: I wonder how it is that no one actually had problem with this?
This predictably fails on `session login` on pharo, unless
queryEncoding is somehow magically present without seeing it in
source code for other platforms?


2017-08-05 15:52 GMT-03:00 Herby Vojčík mailto:he...@mailbox.sk>
>>:

Alistair Grant wrote:

Hi Herby,

On 5 August 2017 at 18:09, Herby
Vojčíkmailto:he...@mailbox.sk>
>> wrote:

Hello!

First of all, what is preferred way to (first time)
login
into database? I
had the impression that `aDatabaseAccessor login`
is sorta
low-level, and
one should do `session login` (after all, it is
session you
get to work
with, not an accessor).

But with Garage SQLite, `session login`, when
accessor is
not logged, always
fails with "MessageNotUnderstood:
GASqlite3Driver>>queryEncoding".

Should one not use `session login` at all, then (when
accessor is logged, it
just does nothing, if it isn't, it connects the
accessor,
but tries to do
some additional work which always fails)?

Herby


From memory this is caused by differences between
VisualWorks
and Pharo.

Anyway, it is discussed and resolved in:

http://forum.world.st/Glorp-SQLite3-issue-td4899792.html

>


Doesn't look like solved to me. Anyway, at least I know it
is known
for year and no-one seemed to see it as a bug.

I think it is one (you cannot just send queryEncoding where
no class
implements it and be fine, imo).

So what is the state of `session login`? Is it meant to be
used, or
everyone just took a step down to low-level and uses `accessor
login` instead? :-(


Cheers,
Alistair


Thanks, Herby






--



Guille Polito


Research Engineer

French National Center for Scientific Research - _http://www.cnrs.fr_



*Web:* _http://guillep.github.io_

*Phone: *+33 06 52 70 66 13

Re: [Pharo-users] Glorp: `session login` fails for Garage SQLite

2017-08-05 Thread Herby Vojčík 

Guillermo Polito wrote:

AFAIR, PharoDatabaseAccessor was meant to work with SqueakDBX/DBXTalk
driver. No other driver should use it. At the time Garage did not even
exist.

So I'd say that you should not use PharoDatabaseAccessor with another
driver than the one it was originally mean to? I do not know exactly
your setup, I was not following this thread.

Really I cannot tell much more. This was really long time ago.


Great to know!

I am not using it consciously, though. System somehow selects it and 
uses it in the background (I just do MyDescriptorSystem sessionForLogin: 
myLoginObject; and before that I set GarageGlorpDrive to be the default).


This seems to be the actual fix (make Glorp with Garage not use 
PharoDatabaseAccessor).


Herby



On Sun, Aug 6, 2017 at 12:20 AM, Herby Vojčík mailto:he...@mailbox.sk>> wrote:

Esteban A. Maringolo wrote:

Herby,

I regularly use `session login`, but I don't use SQLite in
Pharo, but I
do in VisualWorks and it works just fine.
Maybe if there is a bug we should fix it. Even with a no-op method.

Regards!

Esteban A. Maringolo


It's hard. The problem is

PharoDatabaseAccessor >> encoding
  ^self connection queryEncoding

which overrides parent, which is atm:

encoding
"The connection is specific to the dialect;  some dialects will need
to override this method."

 ^connection encoding

The former was added at GuillermoPolito.73 back in 2011 (and the
latter was the same back then). It probably fixed something, but I
don't see any implementors of queryEncoding atm (definitely not in
Garage). From the diff it is clear lots of databases and drivers
have gone. Now, why was it change for Pharo (and does it need to be
changed in 2017)?

Ccing Guillermo Polito.

Herby

P.S.: I wonder how it is that no one actually had problem with this?
This predictably fails on `session login` on pharo, unless
queryEncoding is somehow magically present without seeing it in
source code for other platforms?


2017-08-05 15:52 GMT-03:00 Herby Vojčík mailto:he...@mailbox.sk>
>>:

 Alistair Grant wrote:

 Hi Herby,

 On 5 August 2017 at 18:09, Herby
Vojčíkmailto:he...@mailbox.sk>
>>  wrote:

 Hello!

 First of all, what is preferred way to (first time)
login
 into database? I
 had the impression that `aDatabaseAccessor login`
is sorta
 low-level, and
 one should do `session login` (after all, it is
session you
 get to work
 with, not an accessor).

 But with Garage SQLite, `session login`, when
accessor is
 not logged, always
 fails with "MessageNotUnderstood:
 GASqlite3Driver>>queryEncoding".

 Should one not use `session login` at all, then (when
 accessor is logged, it
 just does nothing, if it isn't, it connects the
accessor,
 but tries to do
 some additional work which always fails)?

 Herby


   From memory this is caused by differences between
VisualWorks
 and Pharo.

 Anyway, it is discussed and resolved in:

http://forum.world.st/Glorp-SQLite3-issue-td4899792.html

>


 Doesn't look like solved to me. Anyway, at least I know it
is known
 for year and no-one seemed to see it as a bug.

 I think it is one (you cannot just send queryEncoding where
no class
 implements it and be fine, imo).

 So what is the state of `session login`? Is it meant to be
used, or
 everyone just took a step down to low-level and uses `accessor
 login` instead? :-(


 Cheers,
 Alistair


 Thanks, Herby






--



Guille Polito


Research Engineer

French National Center for Scientific Research - _http://www.cnrs.fr_



*Web:* _http://guillep.github.io_

*Phone: *+33 06 52 70 66 13

Re: [Pharo-users] Glorp: `session login` fails for Garage SQLite

2017-08-05 Thread Herby Vojčík 

Esteban A. Maringolo wrote:

Which version of Pharo, Glorp and SQLite are you using?


As for SQLite dll, I don't know (does it change the fact if 
queryEncoding method is present?).


Pharo is 6.1, Glorp, Garage etc. are #stable loaded from Pharo60 catalog 
(see attachment).


Herby




Esteban A. Maringolo


2017-08-05 19:20 GMT-03:00 Herby Vojčík:

Esteban A. Maringolo wrote:

Herby,

I regularly use `session login`, but I don't use SQLite in Pharo, but I
do in VisualWorks and it works just fine.
Maybe if there is a bug we should fix it. Even with a no-op method.

Regards!

Esteban A. Maringolo


It's hard. The problem is

PharoDatabaseAccessor>>  encoding
  ^self connection queryEncoding

which overrides parent, which is atm:

encoding
 "The connection is specific to the dialect;  some dialects will need
to override this method."

 ^connection encoding

The former was added at GuillermoPolito.73 back in 2011 (and the latter was
the same back then). It probably fixed something, but I don't see any
implementors of queryEncoding atm (definitely not in Garage). From the diff
it is clear lots of databases and drivers have gone. Now, why was it change
for Pharo (and does it need to be changed in 2017)?

Ccing Guillermo Polito.

Herby

P.S.: I wonder how it is that no one actually had problem with this? This
predictably fails on `session login` on pharo, unless queryEncoding is
somehow magically present without seeing it in source code for other
platforms?


2017-08-05 15:52 GMT-03:00 Herby Vojčíkmailto:he...@mailbox.sk>>:

 Alistair Grant wrote:

 Hi Herby,

 On 5 August 2017 at 18:09, Herby Vojčíkmailto:he...@mailbox.sk>>   wrote:

 Hello!

 First of all, what is preferred way to (first time) login
 into database? I
 had the impression that `aDatabaseAccessor login` is sorta
 low-level, and
 one should do `session login` (after all, it is session you
 get to work
 with, not an accessor).

 But with Garage SQLite, `session login`, when accessor is
 not logged, always
 fails with "MessageNotUnderstood:
 GASqlite3Driver>>queryEncoding".

 Should one not use `session login` at all, then (when
 accessor is logged, it
 just does nothing, if it isn't, it connects the accessor,
 but tries to do
 some additional work which always fails)?

 Herby


   From memory this is caused by differences between VisualWorks
 and Pharo.

 Anyway, it is discussed and resolved in:

 http://forum.world.st/Glorp-SQLite3-issue-td4899792.html
 


 Doesn't look like solved to me. Anyway, at least I know it is known
 for year and no-one seemed to see it as a bug.

 I think it is one (you cannot just send queryEncoding where no class
 implements it and be fine, imo).

 So what is the state of `session login`? Is it meant to be used, or
 everyone just took a step down to low-level and uses `accessor
 login` instead? :-(


 Cheers,
 Alistair


 Thanks, Herby

Re: [Pharo-users] Glorp: `session login` fails for Garage SQLite

2017-08-05 Thread Esteban A. Maringolo 
Which version of Pharo, Glorp and SQLite are you using?


Esteban A. Maringolo


2017-08-05 19:20 GMT-03:00 Herby Vojčík :
> Esteban A. Maringolo wrote:
>>
>> Herby,
>>
>> I regularly use `session login`, but I don't use SQLite in Pharo, but I
>> do in VisualWorks and it works just fine.
>> Maybe if there is a bug we should fix it. Even with a no-op method.
>>
>> Regards!
>>
>> Esteban A. Maringolo
>
>
> It's hard. The problem is
>
> PharoDatabaseAccessor >> encoding
>  ^self connection queryEncoding
>
> which overrides parent, which is atm:
>
> encoding
> "The connection is specific to the dialect;  some dialects will need
> to override this method."
>
> ^connection encoding
>
> The former was added at GuillermoPolito.73 back in 2011 (and the latter was
> the same back then). It probably fixed something, but I don't see any
> implementors of queryEncoding atm (definitely not in Garage). From the diff
> it is clear lots of databases and drivers have gone. Now, why was it change
> for Pharo (and does it need to be changed in 2017)?
>
> Ccing Guillermo Polito.
>
> Herby
>
> P.S.: I wonder how it is that no one actually had problem with this? This
> predictably fails on `session login` on pharo, unless queryEncoding is
> somehow magically present without seeing it in source code for other
> platforms?
>
>>
>> 2017-08-05 15:52 GMT-03:00 Herby Vojčík > >:
>>
>> Alistair Grant wrote:
>>
>> Hi Herby,
>>
>> On 5 August 2017 at 18:09, Herby Vojčík> >  wrote:
>>
>> Hello!
>>
>> First of all, what is preferred way to (first time) login
>> into database? I
>> had the impression that `aDatabaseAccessor login` is sorta
>> low-level, and
>> one should do `session login` (after all, it is session you
>> get to work
>> with, not an accessor).
>>
>> But with Garage SQLite, `session login`, when accessor is
>> not logged, always
>> fails with "MessageNotUnderstood:
>> GASqlite3Driver>>queryEncoding".
>>
>> Should one not use `session login` at all, then (when
>> accessor is logged, it
>> just does nothing, if it isn't, it connects the accessor,
>> but tries to do
>> some additional work which always fails)?
>>
>> Herby
>>
>>
>>   From memory this is caused by differences between VisualWorks
>> and Pharo.
>>
>> Anyway, it is discussed and resolved in:
>>
>> http://forum.world.st/Glorp-SQLite3-issue-td4899792.html
>> 
>>
>>
>> Doesn't look like solved to me. Anyway, at least I know it is known
>> for year and no-one seemed to see it as a bug.
>>
>> I think it is one (you cannot just send queryEncoding where no class
>> implements it and be fine, imo).
>>
>> So what is the state of `session login`? Is it meant to be used, or
>> everyone just took a step down to low-level and uses `accessor
>> login` instead? :-(
>>
>>
>> Cheers,
>> Alistair
>>
>>
>> Thanks, Herby
>>
>>
>
>

Re: [Pharo-users] Glorp: `session login` fails for Garage SQLite

2017-08-05 Thread Guillermo Polito 
AFAIR, PharoDatabaseAccessor was meant to work with SqueakDBX/DBXTalk
driver. No other driver should use it. At the time Garage did not even
exist.

So I'd say that you should not use PharoDatabaseAccessor with another
driver than the one it was originally mean to? I do not know exactly your
setup, I was not following this thread.

Really I cannot tell much more. This was really long time ago.

On Sun, Aug 6, 2017 at 12:20 AM, Herby Vojčík  wrote:

> Esteban A. Maringolo wrote:
>
>> Herby,
>>
>> I regularly use `session login`, but I don't use SQLite in Pharo, but I
>> do in VisualWorks and it works just fine.
>> Maybe if there is a bug we should fix it. Even with a no-op method.
>>
>> Regards!
>>
>> Esteban A. Maringolo
>>
>
> It's hard. The problem is
>
> PharoDatabaseAccessor >> encoding
>  ^self connection queryEncoding
>
> which overrides parent, which is atm:
>
> encoding
> "The connection is specific to the dialect;  some dialects will
> need to override this method."
>
> ^connection encoding
>
> The former was added at GuillermoPolito.73 back in 2011 (and the latter
> was the same back then). It probably fixed something, but I don't see any
> implementors of queryEncoding atm (definitely not in Garage). From the diff
> it is clear lots of databases and drivers have gone. Now, why was it change
> for Pharo (and does it need to be changed in 2017)?
>
> Ccing Guillermo Polito.
>
> Herby
>
> P.S.: I wonder how it is that no one actually had problem with this? This
> predictably fails on `session login` on pharo, unless queryEncoding is
> somehow magically present without seeing it in source code for other
> platforms?
>
>
>> 2017-08-05 15:52 GMT-03:00 Herby Vojčík > >:
>>
>> Alistair Grant wrote:
>>
>> Hi Herby,
>>
>> On 5 August 2017 at 18:09, Herby Vojčík> >  wrote:
>>
>> Hello!
>>
>> First of all, what is preferred way to (first time) login
>> into database? I
>> had the impression that `aDatabaseAccessor login` is sorta
>> low-level, and
>> one should do `session login` (after all, it is session you
>> get to work
>> with, not an accessor).
>>
>> But with Garage SQLite, `session login`, when accessor is
>> not logged, always
>> fails with "MessageNotUnderstood:
>> GASqlite3Driver>>queryEncoding".
>>
>> Should one not use `session login` at all, then (when
>> accessor is logged, it
>> just does nothing, if it isn't, it connects the accessor,
>> but tries to do
>> some additional work which always fails)?
>>
>> Herby
>>
>>
>>   From memory this is caused by differences between VisualWorks
>> and Pharo.
>>
>> Anyway, it is discussed and resolved in:
>>
>> http://forum.world.st/Glorp-SQLite3-issue-td4899792.html
>> 
>>
>>
>> Doesn't look like solved to me. Anyway, at least I know it is known
>> for year and no-one seemed to see it as a bug.
>>
>> I think it is one (you cannot just send queryEncoding where no class
>> implements it and be fine, imo).
>>
>> So what is the state of `session login`? Is it meant to be used, or
>> everyone just took a step down to low-level and uses `accessor
>> login` instead? :-(
>>
>>
>> Cheers,
>> Alistair
>>
>>
>> Thanks, Herby
>>
>>
>>
>


-- 



Guille Polito


Research Engineer

French National Center for Scientific Research - *http://www.cnrs.fr*




*Web:* *http://guillep.github.io* 

*Phone: *+33 06 52 70 66 13

Re: [Pharo-users] Glorp: `session login` fails for Garage SQLite

2017-08-05 Thread Herby Vojčík 

Esteban A. Maringolo wrote:

Herby,

I regularly use `session login`, but I don't use SQLite in Pharo, but I
do in VisualWorks and it works just fine.
Maybe if there is a bug we should fix it. Even with a no-op method.

Regards!

Esteban A. Maringolo


It's hard. The problem is

PharoDatabaseAccessor >> encoding
 ^self connection queryEncoding

which overrides parent, which is atm:

encoding
	"The connection is specific to the dialect;  some dialects will need to 
override this method."


^connection encoding

The former was added at GuillermoPolito.73 back in 2011 (and the latter 
was the same back then). It probably fixed something, but I don't see 
any implementors of queryEncoding atm (definitely not in Garage). From 
the diff it is clear lots of databases and drivers have gone. Now, why 
was it change for Pharo (and does it need to be changed in 2017)?


Ccing Guillermo Polito.

Herby

P.S.: I wonder how it is that no one actually had problem with this? 
This predictably fails on `session login` on pharo, unless queryEncoding 
is somehow magically present without seeing it in source code for other 
platforms?




2017-08-05 15:52 GMT-03:00 Herby Vojčík mailto:he...@mailbox.sk>>:

Alistair Grant wrote:

Hi Herby,

On 5 August 2017 at 18:09, Herby Vojčíkmailto:he...@mailbox.sk>>  wrote:

Hello!

First of all, what is preferred way to (first time) login
into database? I
had the impression that `aDatabaseAccessor login` is sorta
low-level, and
one should do `session login` (after all, it is session you
get to work
with, not an accessor).

But with Garage SQLite, `session login`, when accessor is
not logged, always
fails with "MessageNotUnderstood:
GASqlite3Driver>>queryEncoding".

Should one not use `session login` at all, then (when
accessor is logged, it
just does nothing, if it isn't, it connects the accessor,
but tries to do
some additional work which always fails)?

Herby


  From memory this is caused by differences between VisualWorks
and Pharo.

Anyway, it is discussed and resolved in:

http://forum.world.st/Glorp-SQLite3-issue-td4899792.html



Doesn't look like solved to me. Anyway, at least I know it is known
for year and no-one seemed to see it as a bug.

I think it is one (you cannot just send queryEncoding where no class
implements it and be fine, imo).

So what is the state of `session login`? Is it meant to be used, or
everyone just took a step down to low-level and uses `accessor
login` instead? :-(


Cheers,
Alistair


Thanks, Herby

Re: [Pharo-users] Glorp: `session login` fails for Garage SQLite

2017-08-05 Thread Esteban A. Maringolo 
Herby,

I regularly use `session login`, but I don't use SQLite in Pharo, but I do
in VisualWorks and it works just fine.
Maybe if there is a bug we should fix it. Even with a no-op method.

Regards!

Esteban A. Maringolo

2017-08-05 15:52 GMT-03:00 Herby Vojčík :

> Alistair Grant wrote:
>
>> Hi Herby,
>>
>> On 5 August 2017 at 18:09, Herby Vojčík  wrote:
>>
>>> Hello!
>>>
>>> First of all, what is preferred way to (first time) login into database?
>>> I
>>> had the impression that `aDatabaseAccessor login` is sorta low-level, and
>>> one should do `session login` (after all, it is session you get to work
>>> with, not an accessor).
>>>
>>> But with Garage SQLite, `session login`, when accessor is not logged,
>>> always
>>> fails with "MessageNotUnderstood: GASqlite3Driver>>queryEncoding".
>>>
>>> Should one not use `session login` at all, then (when accessor is
>>> logged, it
>>> just does nothing, if it isn't, it connects the accessor, but tries to do
>>> some additional work which always fails)?
>>>
>>> Herby
>>>
>>
>>  From memory this is caused by differences between VisualWorks and Pharo.
>>
>> Anyway, it is discussed and resolved in:
>>
>> http://forum.world.st/Glorp-SQLite3-issue-td4899792.html
>>
>
> Doesn't look like solved to me. Anyway, at least I know it is known for
> year and no-one seemed to see it as a bug.
>
> I think it is one (you cannot just send queryEncoding where no class
> implements it and be fine, imo).
>
> So what is the state of `session login`? Is it meant to be used, or
> everyone just took a step down to low-level and uses `accessor login`
> instead? :-(
>
>
>> Cheers,
>> Alistair
>>
>>
> Thanks, Herby
>
>

Re: [Pharo-users] Glorp: `session login` fails for Garage SQLite

2017-08-05 Thread Herby Vojčík 

Alistair Grant wrote:

Hi Herby,

On 5 August 2017 at 18:09, Herby Vojčík  wrote:

Hello!

First of all, what is preferred way to (first time) login into database? I
had the impression that `aDatabaseAccessor login` is sorta low-level, and
one should do `session login` (after all, it is session you get to work
with, not an accessor).

But with Garage SQLite, `session login`, when accessor is not logged, always
fails with "MessageNotUnderstood: GASqlite3Driver>>queryEncoding".

Should one not use `session login` at all, then (when accessor is logged, it
just does nothing, if it isn't, it connects the accessor, but tries to do
some additional work which always fails)?

Herby


 From memory this is caused by differences between VisualWorks and Pharo.

Anyway, it is discussed and resolved in:

http://forum.world.st/Glorp-SQLite3-issue-td4899792.html


Doesn't look like solved to me. Anyway, at least I know it is known for 
year and no-one seemed to see it as a bug.


I think it is one (you cannot just send queryEncoding where no class 
implements it and be fine, imo).


So what is the state of `session login`? Is it meant to be used, or 
everyone just took a step down to low-level and uses `accessor login` 
instead? :-(




Cheers,
Alistair



Thanks, Herby

Re: [Pharo-users] Glorp: `session login` fails for Garage SQLite

2017-08-05 Thread Alistair Grant 
Hi Herby,

On 5 August 2017 at 18:09, Herby Vojčík  wrote:
> Hello!
>
> First of all, what is preferred way to (first time) login into database? I
> had the impression that `aDatabaseAccessor login` is sorta low-level, and
> one should do `session login` (after all, it is session you get to work
> with, not an accessor).
>
> But with Garage SQLite, `session login`, when accessor is not logged, always
> fails with "MessageNotUnderstood: GASqlite3Driver>>queryEncoding".
>
> Should one not use `session login` at all, then (when accessor is logged, it
> just does nothing, if it isn't, it connects the accessor, but tries to do
> some additional work which always fails)?
>
> Herby

>From memory this is caused by differences between VisualWorks and Pharo.

Anyway, it is discussed and resolved in:

http://forum.world.st/Glorp-SQLite3-issue-td4899792.html

Cheers,
Alistair