Hi, Trying to play with multiple repo, it occurs Voyage hangs the image with the script bellow: | orga repo1 repo2| repo1 := VOMongoRepository host: 'localhost' database: 'test1'. repo2 := VOMongoRepository host: 'localhost' database: 'test2'. orga := CGOrganisation new name: 'Pharo'; id: 0; yourself. repo1 save: orga. repo2 save: (CGUser new id: 0; name: 'Hilaire'; organisation: orga; yourself). repo1 reset. repo2 reset. repo1 := repo2 := nil. repo1 := VOMongoRepository host: 'localhost' database: 'test1'. (repo1 selectAll: CGOrganisation) inspect. "<- HANG here" The initial save is properly done in the MongoDB, I can see its content from the Mongo shell. Looking at the Mong log, there are connexion in and out: Tue Feb 21 21:44:39.016 [conn508568] end connection 127.0.0.1:34469 (20 connections now open) Tue Feb 21 21:44:39.016 [initandlisten] connection accepted from 127.0.0.1:34470 #508569 (21 connections now open) Tue Feb 21 21:44:39.016 [conn508569] end connection 127.0.0.1:34470 (20 connections now open) Tue Feb 21 21:44:39.017 [initandlisten] connection accepted from 127.0.0.1:34471 #508570 (21 connections now open) Tue Feb 21 21:44:39.017 [conn508570] end connection 127.0.0.1:34471 (20 connections now open) Tue Feb 21 21:44:39.017 [initandlisten] connection accepted from 127.0.0.1:34472 #508571 (21 connections now open) Tue Feb 21 21:44:39.018 [conn508571] end connection 127.0.0.1:34472 (20 connections now open) Tue Feb 21 21:44:39.018 [initandlisten] connection accepted from 127.0.0.1:34473 #508572 (21 connections now open) Tue Feb 21 21:44:39.018 [conn508572] end connection 127.0.0.1:34473 (20 connections now open) Tue Feb 21 21:44:39.018 [initandlisten] connection accepted from 127.0.0.1:34474 #508573 (21 connections now open) Tue Feb 21 21:44:39.019 [conn508573] end connection 127.0.0.1:34474 (20 connections now open) Luckily, I can get back image control with Alt+[.] What's wrong? Thanks Hilaire -- Dr. Geo http://drgeo.eu
Hi Hilaire, thatâs not enough information⦠where it hangs? (when you get the debugger after cmd+.)? Esteban
On 21 Feb 2017, at 21:52, Hilaire <hilaire@drgeo.eu> wrote:
Hi,
Trying to play with multiple repo, it occurs Voyage hangs the image with the script bellow:
| orga repo1 repo2| repo1 := VOMongoRepository host: 'localhost' database: 'test1'. repo2 := VOMongoRepository host: 'localhost' database: 'test2'. orga := CGOrganisation new name: 'Pharo'; id: 0; yourself. repo1 save: orga. repo2 save: (CGUser new id: 0; name: 'Hilaire'; organisation: orga; yourself). repo1 reset. repo2 reset. repo1 := repo2 := nil. repo1 := VOMongoRepository host: 'localhost' database: 'test1'. (repo1 selectAll: CGOrganisation) inspect. "<- HANG here"
The initial save is properly done in the MongoDB, I can see its content from the Mongo shell.
Looking at the Mong log, there are connexion in and out:
Tue Feb 21 21:44:39.016 [conn508568] end connection 127.0.0.1:34469 (20 connections now open) Tue Feb 21 21:44:39.016 [initandlisten] connection accepted from 127.0.0.1:34470 #508569 (21 connections now open) Tue Feb 21 21:44:39.016 [conn508569] end connection 127.0.0.1:34470 (20 connections now open) Tue Feb 21 21:44:39.017 [initandlisten] connection accepted from 127.0.0.1:34471 #508570 (21 connections now open) Tue Feb 21 21:44:39.017 [conn508570] end connection 127.0.0.1:34471 (20 connections now open) Tue Feb 21 21:44:39.017 [initandlisten] connection accepted from 127.0.0.1:34472 #508571 (21 connections now open) Tue Feb 21 21:44:39.018 [conn508571] end connection 127.0.0.1:34472 (20 connections now open) Tue Feb 21 21:44:39.018 [initandlisten] connection accepted from 127.0.0.1:34473 #508572 (21 connections now open) Tue Feb 21 21:44:39.018 [conn508572] end connection 127.0.0.1:34473 (20 connections now open) Tue Feb 21 21:44:39.018 [initandlisten] connection accepted from 127.0.0.1:34474 #508573 (21 connections now open) Tue Feb 21 21:44:39.019 [conn508573] end connection 127.0.0.1:34474 (20 connections now open)
Luckily, I can get back image control with Alt+[.]
What's wrong?
Thanks
Hilaire
-- Dr. Geo http://drgeo.eu
Le 22/02/2017 à 12:18, Esteban Lorenzano a écrit :
thatâs not enough information⦠where it hangs? (when you get the debugger after cmd+.)?
It looks like Voyage is trapped in a loop. When I execute the following code in singleton it hangs as well: | orga repo| repo := VOMongoRepository host: 'localhost' database: 'MaBase'. repo enableSingleton. orga := String fromString: 'Pharo'. orga save. Then I can press atl+., I got the attached Pharo debug log. At some point I used wrongly Voyage, from there I got problem. Thanks Hilaire -- Dr. Geo http://drgeo.eu
did you marked the class as âvoyage rootâ? Esteban
On 22 Feb 2017, at 14:18, Hilaire <hilaire@drgeo.eu> wrote:
Le 22/02/2017 à 12:18, Esteban Lorenzano a écrit :
thatâs not enough information⦠where it hangs? (when you get the debugger after cmd+.)?
It looks like Voyage is trapped in a loop. When I execute the following code in singleton it hangs as well:
| orga repo| repo := VOMongoRepository host: 'localhost' database: 'MaBase'. repo enableSingleton. orga := String fromString: 'Pharo'. orga save.
Then I can press atl+., I got the attached Pharo debug log.
At some point I used wrongly Voyage, from there I got problem.
Thanks
Hilaire
-- Dr. Geo http://drgeo.eu <PharoDebug.log>
Yes, I marked the class String as voyage root. Should it be ByteArray? Hilaire Le 22/02/2017 à 14:30, Esteban Lorenzano a écrit :
did you marked the class as âvoyage rootâ?
-- Dr. Geo http://drgeo.eu
On 22 Feb 2017, at 14:36, Hilaire <hilaire@drgeo.eu> wrote:
Yes, I marked the class String as voyage root. Should it be ByteArray?
no, but String probably will be complicated to persist âas isâ (is not directly mappeable to a JSON/BSON object). Better to test with another object (like your original post). we need to see what is the error youâre getting⦠the loop seems to be happening in a resignalAs: so there is an error somewhere (not that is good it resignal it instead showing it, but letâs go in parts :P) Esteban
Hilaire
Le 22/02/2017 à 14:30, Esteban Lorenzano a écrit :
did you marked the class as âvoyage rootâ?
-- Dr. Geo http://drgeo.eu
I though String may be problematic, so I try with Association. The problem still occurs at, self collectionAt: anObject class inDatabase: db There I can see at least a command failed error. The collection can't be added. In addCollection: aString capped: aCapped size: aSize max: aMax, the reply from DB is: a Dictionary('code'->15888 'errmsg'->'exception: must pass name of collection to create' 'ok'->0.0 ) Le 22/02/2017 à 14:40, Esteban Lorenzano a écrit :
no, but String probably will be complicated to persist âas isâ (is not directly mappeable to a JSON/BSON object). Better to test with another object (like your original post). we need to see what is the error youâre getting⦠the loop seems to be happening in a resignalAs: so there is an error somewhere (not that is good it resignal it instead showing it, but letâs go in parts :P)
Esteban
-- Dr. Geo http://drgeo.eu
It looks like the collection name by default is a symbol, and Mongo does not like it. In my example aString = #Association A asString conversion seems to please it. addCollection: aString capped: aCapped size: aSize max: aMax | command reply | command := SmallDictionary new. command at: 'create' put: aString asString. Regarding default voyageCollectionName, it indeeds return a Symbol. Association voyageCollectionName. => #Association By an extraordinatry circumstance, when apply to my domain object, it returns a string, therefore I did not notice the problem before: CGOrganisation voyageCollectionName. => 'Organisations' Not sure it is the exact cause of the problem. Hilaire -- Dr. Geo http://drgeo.eu
yes, there was a bug around that, now I remember. and probably the version for Pharo 4 does not have the fix⦠I do not remember exactly where was the problem, let me review a bit... Esteban
On 22 Feb 2017, at 14:51, Hilaire <hilaire@drgeo.eu> wrote:
I though String may be problematic, so I try with Association. The problem still occurs at, self collectionAt: anObject class inDatabase: db
There I can see at least a command failed error. The collection can't be added.
In addCollection: aString capped: aCapped size: aSize max: aMax, the reply from DB is:
a Dictionary('code'->15888 'errmsg'->'exception: must pass name of collection to create' 'ok'->0.0 )
Le 22/02/2017 à 14:40, Esteban Lorenzano a écrit :
no, but String probably will be complicated to persist âas isâ (is not directly mappeable to a JSON/BSON object). Better to test with another object (like your original post). we need to see what is the error youâre getting⦠the loop seems to be happening in a resignalAs: so there is an error somewhere (not that is good it resignal it instead showing it, but letâs go in parts :P)
Esteban
-- Dr. Geo http://drgeo.eu
So far, I edited this method, adding a final string conversion: voyageCollectionName "This method can be overridden with a more meaningful collection name" ^ (((self persistentClass name first: 3) allSatisfy: #isUppercase) ifTrue: [ (self persistentClass name allButFirst: 2) ] ifFalse: [ self persistentClass name ]) asString Le 22/02/2017 à 15:02, Esteban Lorenzano a écrit :
yes, there was a bug around that, now I remember. and probably the version for Pharo 4 does not have the fix⦠I do not remember exactly where was the problem, let me review a bit...
-- Dr. Geo http://drgeo.eu
yep, that can be the problem: symbol/string incompatibilities Esteban
On 22 Feb 2017, at 15:05, Hilaire <hilaire@drgeo.eu> wrote:
So far, I edited this method, adding a final string conversion:
voyageCollectionName "This method can be overridden with a more meaningful collection name" ^ (((self persistentClass name first: 3) allSatisfy: #isUppercase) ifTrue: [ (self persistentClass name allButFirst: 2) ] ifFalse: [ self persistentClass name ]) asString
Le 22/02/2017 à 15:02, Esteban Lorenzano a écrit :
yes, there was a bug around that, now I remember. and probably the version for Pharo 4 does not have the fix⦠I do not remember exactly where was the problem, let me review a bit...
-- Dr. Geo http://drgeo.eu
Here is the version I have, not sure it is the right way to get the version number: ConfigurationOfVoyageMongo project currentVersion >=1.3.3 [ConfigurationOfVoyageMongo] Le 22/02/2017 à 15:02, Esteban Lorenzano a écrit :
and probably the version for Pharo 4 does not have the fix⦠I do not remember exactly where was the problem, let me review a bit...
-- Dr. Geo http://drgeo.eu
I know, but I donât know what it has or has not that version. Esteban
On 22 Feb 2017, at 15:15, Hilaire <hilaire@drgeo.eu> wrote:
Here is the version I have, not sure it is the right way to get the version number:
ConfigurationOfVoyageMongo project currentVersion >=1.3.3 [ConfigurationOfVoyageMongo]
Le 22/02/2017 à 15:02, Esteban Lorenzano a écrit :
and probably the version for Pharo 4 does not have the fix⦠I do not remember exactly where was the problem, let me review a bit...
-- Dr. Geo http://drgeo.eu
Got it! Hilaire Le 22/02/2017 à 15:22, Esteban Lorenzano a écrit :
I know, but I donât know what it has or has not that version.
-- Dr. Geo http://drgeo.eu
participants (2)
-
Esteban Lorenzano -
Hilaire