Re: [Pharo-users] voyage mongo and transactionality

[sebastianconcept]

Hi guys,

I came to this post today due to having what can be described as an
unexpected voyage behavior and was greatly impressed by all the detailed
descriptions and explanations. Thanks everybody for that!

Also thanks Peter for mentioning that port I did back in the day (~2009) for
using OmniBase [1] in Aiflowing [2] where it achieved sub-second page
renderings with a full ACID, multi-image scalable setup. Is not actively
maintained but I think is a piece of software that is worth not having it
lost. The concept alone, filesystem based B-Tree object persistance, is neat
and can be the foundation of a lot of stuff.

Now I wonder what Esteban's fork has that couldn't be a merge request, I
would gladly take a look if open.

I feel bad about you loosing time with testBTreeKeyLocking because you won't
find the issue inside smalltalk. As it depends on the OS' file system to
detect concurrent changes in an object, you need the kernel of that system
to be supporting mandatory lockings [3] which is a feature that linux and
macOS does not have turned on by default. As mentioned in the readme of the
project you need to activate it in order to OmniBase raise an exception
preventing you of a race condition writing an object (coming it from a
transaction from another image or from another thread in that very image)
that would create db corruption or inconsistency. Note that, with mandatory
locking active in your OS kernel, the transaction that comes later will
raise an exception hence that test will pass. By the way, Windows has
mandatory locking by default.

*Back to the issue about voyage* here, I see the whole issue happening
simply because Voyage is caching by default hence forcing all Voyage users
to deal with one of the nastiest problems in computing: cache invalidation.

Yesterday I faced this issue: 
1. changed a mongo document from a mongo client and 
2. querying it from Voyage revealed different state (the state before 1).

This makes no sense at all. It makes Voyage not to be useful for
interoperation with other applications and languages, it makes it impossible
to scale an application in more than one Pharo image (all the main well
proven cloud platforms requires stateless built artifacts to horizontally
scale apps), on top of the lack of horizontal scaling issue there is the
issue of high availability that now you can't do because you are forced to
have a single point of failure (one vm behind the load balancer instead of
N).

But all those issues go away if Voyage simply does what a persistent client
is normally expected to do: save and query documents in the mongo
repository. By trying to do too much, like deciding that caching all inside
the session open in a given image is a valid design, it actually becomes
less powerful and surprises users in the worst way. Might be valid for a
prototype but certainly not for high-availability and high-load demanding
applications in production.

Caching is a great thing but is an application design decision, not a
persistency client decision. That concern is not for the client but for the
engineers who use it to make an application that might have /some/ of its
persisted models cached but certainly not all, except on very limited
scenarios. If you think about it, this is how things become niche.

Now in an application where I'm using Voyage expecting that queries return
what is actually in mongo I have to architect things in a way that
workaround this issue, like purging that cache somehow with some kind of
policy (time or a given event).

I like Voyage and I'm grateful for all the effort Esteban and the
contributors are putting into it. I might add a merge request myself. Is
documented, works well, has really nice features and is intuitive. It's just
this /cache all by default/ part that I don't think belongs to it and if
removed it would be a more powerful mongo client.



[1] https://github.com/sebastianconcept/OmniBase
[2] https://pharo.org/success/AirFlowing
[3] In *nix systems it requires mandatory file locking, so be sure you use
mand on your fstab.
https://www.hackinglinuxexposed.com/articles/20030623.html



--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Re: [Pharo-users] voyage mongo and transactionality

[jtuc...@objektfabrik.de]

Jonathan,

I was a bit destracted by work this week, so I am a little late to the 
show...


Am 10.10.19 um 12:26 schrieb Jonathan van Alteren:

Hi Joachim,

Thank you for your feedback.

It feels good to know we're not alone in this :-)


Well, I guess there are far more people in this boat than actually know 
they are ;-)



Unfortunately, the things you describe are familiar to me. My business 
partner Dave West has a lot of experience with applying a behavioral, 
'pure' object design approach. We're looking hard into simplifying 
these matters through the application of inversion of control and by 
making objects as autonomous as they can possible be.
sigh, This is really, really hard. You'd need a guard in the background 
that autonomously register all objects that get 
visited/accessed/modified during an operation and create a memento just 
before this actually happens. Ideally, this would only happen if the 
upcoming operation on that objects modifies its state once the operation 
happens. Or ot would have to clean up non-modified ones after the 
operation finished. I guess this second alternative is even feasible 
using slots and such, but there remain a few questions about 
synchronizing all this and the underlying database transactions...
At the same time, we haven't found the pot of gold at the end of the 
rainbow yet ;-)


You know, sometimes I fear it is better not to have anybody come back 
from that end of the rainbow. They might have found out there is no pot 
or anything similar to one ;-)



Nowadays, a fair amount of applications have a very direct way of 
handling user interactions and resulting state changes. For example, 
the settings of my Firefox browser doesn't have a save button anymore. 
Anything I change looks to be automatically persisted. Perhaps there 
is some value in that approach for 'enterprise' applications as well, 
although I think there will remain a lot of use cases where an 
explicit save will be needed for whatever reason.


Hmm. I am afraid there is a certain distance between changes that only 
affect a single setting value and more complex values that imply a lot 
of recomputation of values in a more complex model. Sometimes you also 
need to modify or at least check consequences of changes that don't fit 
onto a single screen, and there you need to find ways to allow a user to 
step back from what they just started to do...





Let's keep talking about this. I need to do some research on the 
memento pattern first :-) If you have any information sources you can 
point me to, I would greatly appreciate that.


I don't follow any interesting research on mementos. Too much work to do 
for that. The memento pattern itself is just "make a copy that the user 
can play with without any consequences to the original object". Works 
perfect for a single object or a well-defined object graph. But I am not 
aware of any working solutions that would solve our problems for more 
complex graphs, or even a general one... If you find something, let us know!



Joachim





Kind regards,

Jonathan van Alteren

Founding Member | Object Guild
jvalte...@objectguild.com
On 9 Oct 2019, 16:49 +0200, jtuc...@objektfabrik.de 
, wrote:


This is a tricky mine field. Sometimes you need a lot of business 
functionality in objects referenced in your objects that are 
currently in the editor. So I'm still to see a project in which the 
memento pattern really worked for more complex scenarios. How deep do 
you dive to have enough memento objects to provide the functionality 
needed. I guess you can do that with some sort of object-level 
transaction framework that automatically creates mementos of whatever 
object is being navigated to during some kind of processing-context. 
I guess slots could be of use here. But this is not trivial for 
general cases.


In my experience, this problem area makes for the other 70% of the 
time spent on developing GUI or Web applications, besides the 60% for 
GUI design and implementation and 25% business logic...


I'd be interested to learn about patterns to handle such more complex 
things. We constantly travel back and forth between implementing 
stuff in the GUI handlers (copying values to the GUI classes that 
access themselves during GUI operations and push values to the 
business objects when the users clicks on OK), using mementos (which 
most of the times are nets of mementos that are created manually - 
"we know what we'll touch in this Editor") and operating on business 
objects directly and relying on the persistence mechanism (Glorp in 
our case) and its rollback behaviour. All three have lots of 
weaknesses and seem to have their place nevertheless.


So this is a very interesting discussion and I think this is an area 
that has not been solved yet.



Joachim







Am 09.10.19 um 16:25 schrieb James Foster:
Thanks for the explanation. And, yes, this is an artifact of your 
design; if you put intermediate values into domain objects then they 

Re: [Pharo-users] voyage mongo and transactionality

[Jonathan van Alteren]

Hi Peter,

Thanks for elaborating. I found the thread on the Pharo users list and looked 
at Esteban's repository.

I'm hesitant to spend much time on it, since that is my scarcest resource at 
the moment.

You can try forking Esteban's repository and committing your modifications 
there. Then you can give them back to Esteban by doing a pull request.


Kind regards,

Jonathan van Alteren

Founding Member | Object Guild
jvalte...@objectguild.com
On 10 Oct 2019, 18:14 +0200, PBKResearch , wrote:
> Hi Jonathan
>
> If you are interested in OmniBase on Pharo, there was a port by Sebastian 
> Sastre in about 2010, which was forked and updated by Esteban Lorenzano in 
> June 2018 (https://github.com/estebanlm/OmniBase). There were a few bugs in 
> the port, which were sorted out by Matias Maretto, ma...@omeleon.de and 
> myself. I have all these corrections in my local repo, but they have never 
> been ported back to Esteban’s github repo, because I don’t know how to do it. 
> So do not use Esteban’s repo until updated.
> Esteban’s port was for Pharo 6, and in the case of marco and me was only 
> tried on 32 bits. If you decided to install on 64-bit Pharo 7, you would be 
> on new territory. The only problems are likely to be interactions with the 
> file system. As a quick test, I installed Omnibase and tests in 32-bit Pharo 
> 7. One test (#testBTreeKeyLocking) was red, all the rest green – I have not 
> yet traced the cause.
> The biggest problem is likely to be documentation. I have tried only the 
> simplest uses, because that is all I can work out from the slide-show notes. 
> Maybe someone else who has used it more extensively might still have fuller 
> documentation – e.g. Bruno, who also contributed to this thread.
>
> Peter Kenny
>
>
>
> From: Pharo-users  On Behalf Of Jonathan 
> van Alteren
> Sent: 10 October 2019 11:39
> To: Any question about pharo is welcome 
> Subject: Re: [Pharo-users] voyage mongo and transactionality
>
> Hi Peter,
>
> Thanks for your reply.
>
> That sounds very interesting. For similar reasons, I tried to check out 
> Magma. However, since I'm still a novice in Pharo/Smalltalk and it's not very 
> well documented (and mostly refers to Squeak), it's quite painful to figure 
> out how it works and how to get it going in Pharo. Not to mention actually 
> using it in production for an 'enterprise' application for an actual 
> customer... I haven't given that up yet, but currently don't have the time.
>
> I will look into OmniBase. Anything you're willing to share about getting it 
> up and running (in Pharo 7.0 64-bit) is greatly appreciated!
>
>
> Kind regards,
>
> Jonathan van Alteren
>
> Founding Member | Object Guild
> jvalte...@objectguild.com
> On 9 Oct 2019, 20:34 +0200, PBKResearch , wrote:
>
> > It may be irrelevant, but I have been playing recently with OmniBase, which 
> > is a fully object-oriented database system, now over 20 years old, but it 
> > still works very well for my uses. David Gorišek, the author, claims that 
> > it has ACID properties. From my reading, updates operate on a proxy object, 
> > which is not written to the database until an explicit commit is given. A 
> > second transaction accessing the same object will still see the original 
> > until the change is committed. What happens to a proxy which is never 
> > committed is not clear, but if Gorišek is right, the stored data can never 
> > be contaminated. I think a proxy in this sense is equivalent to a memento.
> >
> > Thanks to Esteban Lorenzano, OmniBase is now available on Pharo. The code 
> > is ancient, there is no documentation and obviously no support, but it 
> > might be worth while for someone to try some software archaeology and put 
> > it to use. I have found it possible to create and maintain a small database 
> > of natural language information, and access is fairly quick and easy – and 
> > it’s all Smalltalk.
> > It claims to store all kinds of Smalltalk objects, except block closures, 
> > and skimming through the code it seems to incorporate a serializer similar 
> > to Fuel.
> >
> > The only documentation I have found is a slideshow at 
> > https://www.slideshare.net/esug/omni-baseobjectdatabase. I have found out a 
> > few things about it, if anyone is interested.
> >
> > Peter Kenny
> >
> >
> > From: Pharo-users  On Behalf Of 
> > Norbert Hartl
> > Sent: 09 October 2019 18:08
> > To: Any question about pharo is welcome 
> > Subject: Re: [Pharo-users] voyage mongo and transactionality
> >
> >
> >
> > Am 09.10.2019 um 16:48 schrieb "jtuc...@objektfabrik.de" 
> > :
> > >
&

Re: [Pharo-users] voyage mongo and transactionality

[PBKResearch]

Hi Jonathan

 

If you are interested in OmniBase on Pharo, there was a port by Sebastian 
Sastre in about 2010, which was forked and updated by Esteban Lorenzano in June 
2018 (https://github.com/estebanlm/OmniBase). There were a few bugs in the 
port, which were sorted out by Matias Maretto, ma...@omeleon.de 
<mailto:ma...@omeleon.de>  and myself. I have all these corrections in my local 
repo, but they have never been ported back to Esteban’s github repo, because I 
don’t know how to do it. So do not use Esteban’s repo until updated.

Esteban’s port was for Pharo 6, and in the case of marco and me was only tried 
on 32 bits. If you decided to install on 64-bit Pharo 7, you would be on new 
territory. The only problems are likely to be interactions with the file 
system. As a quick test, I installed Omnibase and tests in 32-bit Pharo 7. One 
test (#testBTreeKeyLocking) was red, all the rest green – I have not yet traced 
the cause. 

The biggest problem is likely to be documentation. I have tried only the 
simplest uses, because that is all I can work out from the slide-show notes. 
Maybe someone else who has used it more extensively might still have fuller 
documentation – e.g. Bruno, who also contributed to this thread.

 

Peter Kenny

 

 

 

From: Pharo-users  On Behalf Of Jonathan 
van Alteren
Sent: 10 October 2019 11:39
To: Any question about pharo is welcome 
Subject: Re: [Pharo-users] voyage mongo and transactionality

 

Hi Peter, 

 

Thanks for your reply.

 

That sounds very interesting. For similar reasons, I tried to check out Magma. 
However, since I'm still a novice in Pharo/Smalltalk and it's not very well 
documented (and mostly refers to Squeak), it's quite painful to figure out how 
it works and how to get it going in Pharo. Not to mention actually using it in 
production for an 'enterprise' application for an actual customer... I haven't 
given that up yet, but currently don't have the time.

 

I will look into OmniBase. Anything you're willing to share about getting it up 
and running (in Pharo 7.0 64-bit) is greatly appreciated!

 

 

Kind regards,

Jonathan van Alteren

Founding Member | Object Guild
jvalte...@objectguild.com <mailto:jvalte...@objectguild.com> 

On 9 Oct 2019, 20:34 +0200, PBKResearch mailto:pe...@pbkresearch.co.uk> >, wrote:



It may be irrelevant, but I have been playing recently with OmniBase, which is 
a fully object-oriented database system, now over 20 years old, but it still 
works very well for my uses. David Gorišek, the author, claims that it has ACID 
properties. From my reading, updates operate on a proxy object, which is not 
written to the database until an explicit commit is given. A second transaction 
accessing the same object will still see the original until the change is 
committed. What happens to a proxy which is never committed is not clear, but 
if Gorišek is right, the stored data can never be contaminated. I think a proxy 
in this sense is equivalent to a memento.

 

Thanks to Esteban Lorenzano, OmniBase is now available on Pharo. The code is 
ancient, there is no documentation and obviously no support, but it might be 
worth while for someone to try some software archaeology and put it to use. I 
have found it possible to create and maintain a small database of natural 
language information, and access is fairly quick and easy – and it’s all 
Smalltalk.

It claims to store all kinds of Smalltalk objects, except block closures, and 
skimming through the code it seems to incorporate a serializer similar to Fuel.

 

The only documentation I have found is a slideshow at  
<https://www.slideshare.net/esug/omni-baseobjectdatabase> 
https://www.slideshare.net/esug/omni-baseobjectdatabase. I have found out a few 
things about it, if anyone is interested.

 

Peter Kenny

 

 

From: Pharo-users < <mailto:pharo-users-boun...@lists.pharo.org> 
pharo-users-boun...@lists.pharo.org> On Behalf Of Norbert Hartl
Sent: 09 October 2019 18:08
To: Any question about pharo is welcome < <mailto:pharo-users@lists.pharo.org> 
pharo-users@lists.pharo.org>
Subject: Re: [Pharo-users] voyage mongo and transactionality

 

 


Am 09.10.2019 um 16:48 schrieb " <mailto:jtuc...@objektfabrik.de> 
jtuc...@objektfabrik.de" < <mailto:jtuc...@objektfabrik.de> 
jtuc...@objektfabrik.de>:

 

This is a tricky mine field. Sometimes you need a lot of business functionality 
in objects referenced in your objects that are currently in the editor. So I'm 
still to see a project in which the memento pattern really worked for more 
complex scenarios. How deep do you dive to have enough memento objects to 
provide the functionality needed. I guess you can do that with some sort of 
object-level transaction framework that automatically creates mementos of 
whatever object is being navigated to during some kind of processing-context. I 
guess slots could be of use here. But this is not trivial for 

Re: [Pharo-users] voyage mongo and transactionality

[Jonathan van Alteren]

Hi,

That clears up some things, and I understand how the 'cache' works now, thanks!

I did a little bit of research on the lifecycle of a Seaside session, but 
wasn't very successful. Largely because there is a lot of different/outdated 
documentation around, including class comments in Pharo, which has caused me to 
get lost 'in the woods'.

I haven't figured out exactly how the session expiration actually operates. The 
class comment of WASession mentions #defaultTimeoutSeconds or #expire, but both 
of these seem to be absent from Seaside. The WAExpirySession class only keeps 
some counters.

Can you perhaps point me in the right direction?

For example, which object manages the Seaside sessions and where can I find 
(and influence) the expiration behavior? How can I be sure that our WASession 
is properly cleaned up so it won't prevent domain model objects from being 
'released' from the weak dictionary that is used by the Voyage 'cache'?



Kind regards,

Jonathan van Alteren

Founding Member | Object Guild
jvalte...@objectguild.com
On 10 Oct 2019, 12:55 +0200, Norbert Hartl , wrote:
> Hi,
>
>
> Am 10.10.2019 um 11:48 schrieb Jonathan van Alteren 
> :
>
> > Hi Norbert,
> >
> > Thank you very much for your extensive answer.
> >
> > For starters, we would be happy to have an option available for the course 
> > grained handling that you mention. I'd be interested to hear if there are 
> > any options besides GemStone available to be used with Voyage/MongoDB.
>
> I think Gematone has a model that serves these use cases really well. In 
> Pharo there is not much that makes your life easy. But most of this problems 
> can be solved sufficiently kust not generically. Every use case has its 
> constraints and you can model a solution for it. The main problem in voyage 
> stays that the cache is per repository. We need to think along that line if a 
> session or request cannot get its private copy of the database object.
>
> > Your mention of the Mongo cache being a weak dictionary is very 
> > interesting, I did not know that (it doesn't seem to be documented). Yes, 
> > the Seaside sessions seem to be the path through which these objects remain 
> > referenced. When I inspect all instances of our session class, I see old 
> > session objects hanging around that still reference our root application 
> > component with the rendering tree containing various references to our 
> > domain model objects.
>
> You asked Esteban about the cache. I answer that here. Everybody stumbles 
> over the name cache and Esteban is reluctant to give it another name 
> The cache is only for establishing identity in the image. The basic thing 
> with objects in an external system is that its identity (location in the 
> heap) becomes an identity parameter like an id. So when you have externalized 
> objects and you load the object with the same id twice in the image you will 
> make sure that there will only be one object for it and the object from the 
> first query and from the second query are identical meaning comparing both 
> with == returns true. So the cache keeps the database reference and the 
> business object in a weak dictionary. If the object with the same id is 
> queried from the database it returns the object it already has. If the object 
> is not referenced anymore the entry will be removed from the cache. It is 
> nothing more than this.
> >
> > Can you tell me why the session objects don't get garbage collected?
> > Should we manually clean up our session object somehow?
> >
> I‘m not sure what you mean. If the session is not referenced than it just 
> means the garbage collector did not remove it. But this won‘t keep the cache 
> from removing the entry. But seaside sessions have an expiry time. So there 
> is a duration while seaside keeps referencing the session and therefor all 
> objects that are kept in the session are still connecte keeping the objects 
> in the voyage cache.
>
> > I must admit I'm a bit out of my comfort zone here, after working in Java 
> > for close to 20 years ;-) We explicitly don't want to use any relational 
> > databases for our own application (perhaps only for integrating with 
> > customer data). I still haven't fully integrated the conceptual differences 
> > in my mental model, about how to work with objects in an image based/object 
> > persistence environment.
> >
> > I did look into using a Voyage repository filter, which is mentioned (or 
> > buried deep I should say ;-)) in this post: 
> > https://pharoweekly.wordpress.com/2017/02/20/consortium-action-13-17-feb/. 
> > What if we were to use a dynamic variable like this for each session 
> > instance? Then at least each user will have her/his own cache. But that 
> > doesn't answer the need for a kind of rollback mechanism within the same 
> > Voyage cache/session. And then there is your comment about potentially 
> > having multiple copies of an identical object...
>
> As I told in my last mail. The session or 

Re: [Pharo-users] voyage mongo and transactionality

[Smalltalk]

I have used OmniBase extensively long ago with Dolphin  Smalltalk (the 
Dolphin repository can be read & writen by Visual  Works too).


Even the Dolphin repository can be under Windows and Linux (using 
Samba). You can distribute instances ODBContainer through a LAN.


OmniBase use "multiversion concurrency control" to hold different 
version of the same object (in different transactions).


OmniBase is pretty cool but if need a lot of indexes (indexes on more 
than one inst var ) you have to solve the problem yourself using 
OmniBase b-trees.


regards

bruno

El 09/10/2019 a las 15:33, PBKResearch escribió:


It may be irrelevant, but I have been playing recently with OmniBase, 
which is a fully object-oriented database system, now over 20 years 
old, but it still works very well for my uses. David Gorišek, the 
author, claims that it has ACID properties. From my reading, updates 
operate on a proxy object, which is not written to the database until 
an explicit commit is given. A second transaction accessing the same 
object will still see the original until the change is committed. What 
happens to a proxy which is never committed is not clear, but if 
Gorišek is right, the stored data can never be contaminated. I think a 
proxy in this sense is equivalent to a memento.


Thanks to Esteban Lorenzano, OmniBase is now available on Pharo. The 
code is ancient, there is no documentation and obviously no support, 
but it might be worth while for someone to try some software 
archaeology and put it to use. I have found it possible to create and 
maintain a small database of natural language information, and access 
is fairly quick and easy – and it’s all Smalltalk.


It claims to store all kinds of Smalltalk objects, except block 
closures, and skimming through the code it seems to incorporate a 
serializer similar to Fuel.


The only documentation I have found is a slideshow at 
https://www.slideshare.net/esug/omni-baseobjectdatabase. I have found 
out a few things about it, if anyone is interested.


Peter Kenny

*From:*Pharo-users  *On Behalf Of 
*Norbert Hartl

*Sent:* 09 October 2019 18:08
*To:* Any question about pharo is welcome 
*Subject:* Re: [Pharo-users] voyage mongo and transactionality


Am 09.10.2019 um 16:48 schrieb "jtuc...@objektfabrik.de 
<mailto:jtuc...@objektfabrik.de>" <mailto:jtuc...@objektfabrik.de>>:


This is a tricky mine field. Sometimes you need a lot of business
functionality in objects referenced in your objects that are
currently in the editor. So I'm still to see a project in which
the memento pattern really worked for more complex scenarios. How
deep do you dive to have enough memento objects to provide the
functionality needed. I guess you can do that with some sort of
object-level transaction framework that automatically creates
mementos of whatever object is being navigated to during some kind
of processing-context. I guess slots could be of use here. But
this is not trivial for general cases.

Yes it is tricky. You can have copies of business objects but you have 
always references to the business objects not pointing to the copy.


And you need to know which objects should be tracked. In Gemstone IIRC 
it is easy as it is the time the object is copied from the stone to 
the gem it is registered in the current transaction. So you can check 
it and committing if it changed because you have to write it back. The 
important point here might be get noticed when a reference is 
acquired. In pharo it is not that easy but could be done if object 
would be reified and interceptable.


In my experience, this problem area makes for the other 70% of the
time spent on developing GUI or Web applications, besides the 60%
for GUI design and implementation and 25% business logic...

70% + 60% + 25% + 30% = 185%

sounds indeed very realistic if it comes to project planning. There 
is even a rule saying that for the first 90% of the project you need 
the first 90% of time and for the last 10% of the project you need the 
second 90% of time.


I'd be interested to learn about patterns to handle such more
complex things. We constantly travel back and forth between
implementing stuff in the GUI handlers (copying values to the GUI
classes that access themselves during GUI operations and push
values to the business objects when the users clicks on OK), using
mementos (which most of the times are nets of mementos that are
created manually - "we know what we'll touch in this Editor") and
operating on business objects directly and relying on the
persistence mechanism (Glorp in our case) and its rollback
behaviour. All three have lots of weaknesses and seem to have
their place nevertheless.

So this is a very interesting discussion and I think this is an
area that has not been solved yet.

I think it isn‘t solved and I find every piece of 

Re: [Pharo-users] voyage mongo and transactionality

[Norbert Hartl]

> Am 10.10.2019 um 12:31 schrieb Jonathan van Alteren 
> :
> 
> Hah, those percentages feel very real to me at the moment :-S
> 
> Can you explain what GemStone IIRC means? (Novice speaking here :-)) If 
> GemStone solves this at the moment an object goes from Stone to Gem, perhaps 
> we can take that architecture as an example and somehow apply it locally 
> within the same image? What would be required for something like that? Just 
> thinking out loud here...
> 
IIRC means „if I remember correctly“ ;)
Gemstone as the name says is a combination of gem and stone. Stone is the 
database part in the system that manages the global heap. A gem is more or less 
what a pharo vm is. When a gem opens a transaction all used objects get copied 
from the stone in the gem heap. On committing  the transaction the gem writes 
back the data to the stone. This is very brief and mostly not exactly like that 
but gives the picture

Norbert
> 
> Kind regards,
> 
> Jonathan van Alteren
> 
> Founding Member | Object Guild
> jvalte...@objectguild.com
>> On 9 Oct 2019, 19:09 +0200, Norbert Hartl , wrote:
>> 
>> 
>> Am 09.10.2019 um 16:48 schrieb "jtuc...@objektfabrik.de" 
>> :
>> 
>>> 
>>> This is a tricky mine field. Sometimes you need a lot of business 
>>> functionality in objects referenced in your objects that are currently in 
>>> the editor. So I'm still to see a project in which the memento pattern 
>>> really worked for more complex scenarios. How deep do you dive to have 
>>> enough memento objects to provide the functionality needed. I guess you can 
>>> do that with some sort of object-level transaction framework that 
>>> automatically creates mementos of whatever object is being navigated to 
>>> during some kind of processing-context. I guess slots could be of use here. 
>>> But this is not trivial for general cases.
>> 
>> Yes it is tricky. You can have copies of business objects but you have 
>> always references to the business objects not pointing to the copy. 
>> And you need to know which objects should be tracked. In Gemstone IIRC it is 
>> easy as it is the time the object is copied from the stone to the gem it is 
>> registered in the current transaction. So you can check it and committing if 
>> it changed because you have to write it back. The important point here might 
>> be get noticed when a reference is acquired. In pharo it is not that easy 
>> but could be done if object would be reified and interceptable. 
>>> In my experience, this problem area makes for the other 70% of the time 
>>> spent on developing GUI or Web applications, besides the 60% for GUI design 
>>> and implementation and 25% business logic...
>>> 
>> 70% + 60% + 25% + 30% = 185%
>> 
>> sounds indeed very realistic if it comes to project planning. There is even 
>> a rule saying that for the first 90% of the project you need the first 90% 
>> of time and for the last 10% of the project you need the second 90% of time. 
>>> I'd be interested to learn about patterns to handle such more complex 
>>> things. We constantly travel back and forth between implementing stuff in 
>>> the GUI handlers (copying values to the GUI classes that access themselves 
>>> during GUI operations and push values to the business objects when the 
>>> users clicks on OK), using mementos (which most of the times are nets of 
>>> mementos that are created manually - "we know what we'll touch in this 
>>> Editor") and operating on business objects directly and relying on the 
>>> persistence mechanism (Glorp in our case) and its rollback behaviour. All 
>>> three have lots of weaknesses and seem to have their place nevertheless.
>>> 
>>> So this is a very interesting discussion and I think this is an area that 
>>> has not been solved yet.
>>> 
>> I think it isn‘t solved and I find every piece of information about it very 
>> interesting.
>> 
>> Norbert
>>> Joachim
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
 Am 09.10.19 um 16:25 schrieb James Foster:
 Thanks for the explanation. And, yes, this is an artifact of your design; 
 if you put intermediate values into domain objects then they will remain 
 in your domain objects to be seen later. From what you’ve described, I 
 don’t see how it would be any different in a non-image environment (Java, 
 C#, etc.), unless you re-read the entire object graph from the database. 
 As someone else mentioned, this would be a good place for the Memento 
 Pattern.
 
 James
 
> On Oct 9, 2019, at 1:59 AM, Jonathan van Alteren 
>  wrote:
> 
> Hi James,
> 
> I see how my explanation might be unclear.
> 
> We have a main form for the agenda and a subform for an item, which is 
> shown using Seaside call/answer. The save button of the subform is 
> clicked, which adds the item to the underlying agenda model object, but 
> the save button of the main form is not clicked by the user. The callback 
> for the main save 

Re: [Pharo-users] voyage mongo and transactionality

[Norbert Hartl]

Hi,


> Am 10.10.2019 um 11:48 schrieb Jonathan van Alteren 
> :
> 
> Hi Norbert,
> 
> Thank you very much for your extensive answer.
> 
> For starters, we would be happy to have an option available for the course 
> grained handling that you mention. I'd be interested to hear if there are any 
> options besides GemStone available to be used with Voyage/MongoDB.

I think Gematone has a model that serves these use cases really well. In Pharo 
there is not much that makes your life easy. But most of this problems can be 
solved sufficiently kust not generically. Every use case has its constraints 
and you can model a solution for it. The main problem in voyage stays that the 
cache is per repository. We need to think along that line if a session or 
request cannot get its private copy of the database object.

> Your mention of the Mongo cache being a weak dictionary is very interesting, 
> I did not know that (it doesn't seem to be documented). Yes, the Seaside 
> sessions seem to be the path through which these objects remain referenced. 
> When I inspect all instances of our session class, I see old session objects 
> hanging around that still reference our root application component with the 
> rendering tree containing various references to our domain model objects.

You asked Esteban about the cache. I answer that here. Everybody stumbles over 
the name cache and Esteban is reluctant to give it another name 
The cache is only for establishing identity in the image. The basic thing with 
objects in an external system is that its identity (location in the heap) 
becomes an identity parameter like an id. So when you have externalized objects 
and you load the object with the same id twice in the image you will make sure 
that there will only be one object for it and the object from the first query 
and from the second query are identical meaning comparing both with == returns 
true. So the cache keeps the database reference and the business object in a 
weak dictionary. If the object with the same id is queried from the database it 
returns the object it already has. If the object is not referenced anymore the 
entry will be removed from the cache. It is nothing more than this.
> 
> Can you tell me why the session objects don't get garbage collected?
> Should we manually clean up our session object somehow?
> 
I‘m not sure what you mean. If the session is not referenced than it just means 
the garbage collector did not remove it. But this won‘t keep the cache from 
removing the entry. But seaside sessions have an expiry time. So there is a 
duration while seaside keeps referencing the session and therefor all objects 
that are kept in the session are still connecte keeping the objects in the 
voyage cache.

> I must admit I'm a bit out of my comfort zone here, after working in Java for 
> close to 20 years ;-) We explicitly don't want to use any relational 
> databases for our own application (perhaps only for integrating with customer 
> data). I still haven't fully integrated the conceptual differences in my 
> mental model, about how to work with objects in an image based/object 
> persistence environment.
> 
> I did look into using a Voyage repository filter, which is mentioned (or 
> buried deep I should say ;-)) in this post: 
> https://pharoweekly.wordpress.com/2017/02/20/consortium-action-13-17-feb/. 
> What if we were to use a dynamic variable like this for each session 
> instance? Then at least each user will have her/his own cache. But that 
> doesn't answer the need for a kind of rollback mechanism within the same 
> Voyage cache/session. And then there is your comment about potentially having 
> multiple copies of an identical object...

As I told in my last mail. The session or request based cache has also problems 
because if you attach an object you queried while in the session/request to 
somewhere more global you introduce subtle bugs. Maybe we need a two level 
cache, one that knows all objects referenced in the image and one that keeps 
the private copies based on the image based cache. This way we could know that 
multiple sessions/request are keeping a copy of the same object and we could 
determine merge conflicts. Need to think more about this
> 
> I wonder what patterns other Seaside 'enterprise' application developers are 
> using.
> 

> You are right, the term object transactionality doesn't make much sense ;-) 
> We are not using Magritte (and probably won't). I don't know much about 
> Magritte, but it feels like it might be incompatible with the behavioral, 
> 'pure' object approach that we want to use. However, I am interested to 
> investigate. Can you recommend any good documentation sources for learning 
> Magritte from an application architecture perspective?
> 
Magritte is a meta description of your objects. It is like having powerful 
annotation objects. These can be used to create different views on your model. 
There is the PhD paper of Lukas Renggli on the net and 

Re: [Pharo-users] voyage mongo and transactionality

[Jonathan van Alteren]

Hi Peter,

Thanks for your reply.

That sounds very interesting. For similar reasons, I tried to check out Magma. 
However, since I'm still a novice in Pharo/Smalltalk and it's not very well 
documented (and mostly refers to Squeak), it's quite painful to figure out how 
it works and how to get it going in Pharo. Not to mention actually using it in 
production for an 'enterprise' application for an actual customer... I haven't 
given that up yet, but currently don't have the time.

I will look into OmniBase. Anything you're willing to share about getting it up 
and running (in Pharo 7.0 64-bit) is greatly appreciated!


Kind regards,

Jonathan van Alteren

Founding Member | Object Guild
jvalte...@objectguild.com
On 9 Oct 2019, 20:34 +0200, PBKResearch , wrote:
> It may be irrelevant, but I have been playing recently with OmniBase, which 
> is a fully object-oriented database system, now over 20 years old, but it 
> still works very well for my uses. David Gorišek, the author, claims that it 
> has ACID properties. From my reading, updates operate on a proxy object, 
> which is not written to the database until an explicit commit is given. A 
> second transaction accessing the same object will still see the original 
> until the change is committed. What happens to a proxy which is never 
> committed is not clear, but if Gorišek is right, the stored data can never be 
> contaminated. I think a proxy in this sense is equivalent to a memento.
>
> Thanks to Esteban Lorenzano, OmniBase is now available on Pharo. The code is 
> ancient, there is no documentation and obviously no support, but it might be 
> worth while for someone to try some software archaeology and put it to use. I 
> have found it possible to create and maintain a small database of natural 
> language information, and access is fairly quick and easy – and it’s all 
> Smalltalk.
> It claims to store all kinds of Smalltalk objects, except block closures, and 
> skimming through the code it seems to incorporate a serializer similar to 
> Fuel.
>
> The only documentation I have found is a slideshow at 
> https://www.slideshare.net/esug/omni-baseobjectdatabase. I have found out a 
> few things about it, if anyone is interested.
>
> Peter Kenny
>
>
> From: Pharo-users  On Behalf Of Norbert 
> Hartl
> Sent: 09 October 2019 18:08
> To: Any question about pharo is welcome 
> Subject: Re: [Pharo-users] voyage mongo and transactionality
>
>
>
> Am 09.10.2019 um 16:48 schrieb "jtuc...@objektfabrik.de" 
> :
> >
> > This is a tricky mine field. Sometimes you need a lot of business 
> > functionality in objects referenced in your objects that are currently in 
> > the editor. So I'm still to see a project in which the memento pattern 
> > really worked for more complex scenarios. How deep do you dive to have 
> > enough memento objects to provide the functionality needed. I guess you can 
> > do that with some sort of object-level transaction framework that 
> > automatically creates mementos of whatever object is being navigated to 
> > during some kind of processing-context. I guess slots could be of use here. 
> > But this is not trivial for general cases.
>
> Yes it is tricky. You can have copies of business objects but you have always 
> references to the business objects not pointing to the copy.
> And you need to know which objects should be tracked. In Gemstone IIRC it is 
> easy as it is the time the object is copied from the stone to the gem it is 
> registered in the current transaction. So you can check it and committing if 
> it changed because you have to write it back. The important point here might 
> be get noticed when a reference is acquired. In pharo it is not that easy but 
> could be done if object would be reified and interceptable.
> > In my experience, this problem area makes for the other 70% of the time 
> > spent on developing GUI or Web applications, besides the 60% for GUI design 
> > and implementation and 25% business logic...
> 70% + 60% + 25% + 30% = 185%
>
> sounds indeed very realistic if it comes to project planning. There is even 
> a rule saying that for the first 90% of the project you need the first 90% of 
> time and for the last 10% of the project you need the second 90% of time.
>
> > I'd be interested to learn about patterns to handle such more complex 
> > things. We constantly travel back and forth between implementing stuff in 
> > the GUI handlers (copying values to the GUI classes that access themselves 
> > during GUI operations and push values to the business objects when the 
> > users clicks on OK), using mementos (which most of the times are nets of 
> > mementos that are created manually - "we know what we'll touch in thi

Re: [Pharo-users] voyage mongo and transactionality

[Jonathan van Alteren]

Hah, those percentages feel very real to me at the moment :-S

Can you explain what GemStone IIRC means? (Novice speaking here :-)) If 
GemStone solves this at the moment an object goes from Stone to Gem, perhaps we 
can take that architecture as an example and somehow apply it locally within 
the same image? What would be required for something like that? Just thinking 
out loud here...


Kind regards,

Jonathan van Alteren

Founding Member | Object Guild
jvalte...@objectguild.com
On 9 Oct 2019, 19:09 +0200, Norbert Hartl , wrote:
>
>
> Am 09.10.2019 um 16:48 schrieb "jtuc...@objektfabrik.de" 
> :
>
> >
> > This is a tricky mine field. Sometimes you need a lot of business 
> > functionality in objects referenced in your objects that are currently in 
> > the editor. So I'm still to see a project in which the memento pattern 
> > really worked for more complex scenarios. How deep do you dive to have 
> > enough memento objects to provide the functionality needed. I guess you can 
> > do that with some sort of object-level transaction framework that 
> > automatically creates mementos of whatever object is being navigated to 
> > during some kind of processing-context. I guess slots could be of use here. 
> > But this is not trivial for general cases.
>
> Yes it is tricky. You can have copies of business objects but you have always 
> references to the business objects not pointing to the copy.
> And you need to know which objects should be tracked. In Gemstone IIRC it is 
> easy as it is the time the object is copied from the stone to the gem it is 
> registered in the current transaction. So you can check it and committing if 
> it changed because you have to write it back. The important point here might 
> be get noticed when a reference is acquired. In pharo it is not that easy but 
> could be done if object would be reified and interceptable.
> > In my experience, this problem area makes for the other 70% of the time 
> > spent on developing GUI or Web applications, besides the 60% for GUI design 
> > and implementation and 25% business logic...
> 70% + 60% + 25% + 30% = 185%
>
> sounds indeed very realistic if it comes to project planning. There is even 
> a rule saying that for the first 90% of the project you need the first 90% of 
> time and for the last 10% of the project you need the second 90% of time.
> > I'd be interested to learn about patterns to handle such more complex 
> > things. We constantly travel back and forth between implementing stuff in 
> > the GUI handlers (copying values to the GUI classes that access themselves 
> > during GUI operations and push values to the business objects when the 
> > users clicks on OK), using mementos (which most of the times are nets of 
> > mementos that are created manually - "we know what we'll touch in this 
> > Editor") and operating on business objects directly and relying on the 
> > persistence mechanism (Glorp in our case) and its rollback behaviour. All 
> > three have lots of weaknesses and seem to have their place nevertheless.
> > So this is a very interesting discussion and I think this is an area that 
> > has not been solved yet.
> I think it isn‘t solved and I find every piece of information about it very 
> interesting.
>
> Norbert
> > Joachim
> >
> >
> >
> >
> >
> >
> > Am 09.10.19 um 16:25 schrieb James Foster:
> > > Thanks for the explanation. And, yes, this is an artifact of your design; 
> > > if you put intermediate values into domain objects then they will remain 
> > > in your domain objects to be seen later. From what you’ve described, I 
> > > don’t see how it would be any different in a non-image environment (Java, 
> > > C#, etc.), unless you re-read the entire object graph from the database. 
> > > As someone else mentioned, this would be a good place for the Memento 
> > > Pattern.
> > >
> > > James
> > >
> > > > On Oct 9, 2019, at 1:59 AM, Jonathan van Alteren 
> > > >  wrote:
> > > >
> > > > Hi James,
> > > >
> > > > I see how my explanation might be unclear.
> > > >
> > > > We have a main form for the agenda and a subform for an item, which is 
> > > > shown using Seaside call/answer. The save button of the subform is 
> > > > clicked, which adds the item to the underlying agenda model object, but 
> > > > the save button of the main form is not clicked by the user. The 
> > > > callback for the main save button sends the save message to the agenda 
> > > > object, causing the database to be updated.
> > > >
> > > > So yes, the browser does submit the data on the subform, it's the main 
> > > > form component that doesn't receive the save button callback. I realize 
> > > > that this is in large part an issue with our design. However, the way 
> > > > object persistence seems to work in the image environment plays a large 
> > > > role.
> > > >
> > > >
> > > > Kind regards,
> > > >
> > > > Jonathan van Alteren
> > > >
> > > > Founding Member | Object Guild
> > > > jvalte...@objectguild.com
> > > > On 8 Oct 2019, 

Re: [Pharo-users] voyage mongo and transactionality

[Jonathan van Alteren]

Hi Joachim,

Thank you for your feedback.

It feels good to know we're not alone in this :-) Unfortunately, the things you 
describe are familiar to me. My business partner Dave West has a lot of 
experience with applying a behavioral, 'pure' object design approach. We're 
looking hard into simplifying these matters through the application of 
inversion of control and by making objects as autonomous as they can possible 
be. At the same time, we haven't found the pot of gold at the end of the 
rainbow yet ;-)

Nowadays, a fair amount of applications have a very direct way of handling user 
interactions and resulting state changes. For example, the settings of my 
Firefox browser doesn't have a save button anymore. Anything I change looks to 
be automatically persisted. Perhaps there is some value in that approach for 
'enterprise' applications as well, although I think there will remain a lot of 
use cases where an explicit save will be needed for whatever reason.

Let's keep talking about this. I need to do some research on the memento 
pattern first :-) If you have any information sources you can point me to, I 
would greatly appreciate that.


Kind regards,

Jonathan van Alteren

Founding Member | Object Guild
jvalte...@objectguild.com
On 9 Oct 2019, 16:49 +0200, jtuc...@objektfabrik.de , 
wrote:
>
> This is a tricky mine field. Sometimes you need a lot of business 
> functionality in objects referenced in your objects that are currently in the 
> editor. So I'm still to see a project in which the memento pattern really 
> worked for more complex scenarios. How deep do you dive to have enough 
> memento objects to provide the functionality needed. I guess you can do that 
> with some sort of object-level transaction framework that automatically 
> creates mementos of whatever object is being navigated to during some kind of 
> processing-context. I guess slots could be of use here. But this is not 
> trivial for general cases.
> In my experience, this problem area makes for the other 70% of the time spent 
> on developing GUI or Web applications, besides the 60% for GUI design and 
> implementation and 25% business logic...
> I'd be interested to learn about patterns to handle such more complex things. 
> We constantly travel back and forth between implementing stuff in the GUI 
> handlers (copying values to the GUI classes that access themselves during GUI 
> operations and push values to the business objects when the users clicks on 
> OK), using mementos (which most of the times are nets of mementos that are 
> created manually - "we know what we'll touch in this Editor") and operating 
> on business objects directly and relying on the persistence mechanism (Glorp 
> in our case) and its rollback behaviour. All three have lots of weaknesses 
> and seem to have their place nevertheless.
> So this is a very interesting discussion and I think this is an area that has 
> not been solved yet.
>
> Joachim
>
>
>
>
>
>
> Am 09.10.19 um 16:25 schrieb James Foster:
> > Thanks for the explanation. And, yes, this is an artifact of your design; 
> > if you put intermediate values into domain objects then they will remain in 
> > your domain objects to be seen later. From what you’ve described, I don’t 
> > see how it would be any different in a non-image environment (Java, C#, 
> > etc.), unless you re-read the entire object graph from the database. As 
> > someone else mentioned, this would be a good place for the Memento Pattern.
> >
> > James
> >
> > > On Oct 9, 2019, at 1:59 AM, Jonathan van Alteren 
> > >  wrote:
> > >
> > > Hi James,
> > >
> > > I see how my explanation might be unclear.
> > >
> > > We have a main form for the agenda and a subform for an item, which is 
> > > shown using Seaside call/answer. The save button of the subform is 
> > > clicked, which adds the item to the underlying agenda model object, but 
> > > the save button of the main form is not clicked by the user. The callback 
> > > for the main save button sends the save message to the agenda object, 
> > > causing the database to be updated.
> > >
> > > So yes, the browser does submit the data on the subform, it's the main 
> > > form component that doesn't receive the save button callback. I realize 
> > > that this is in large part an issue with our design. However, the way 
> > > object persistence seems to work in the image environment plays a large 
> > > role.
> > >
> > >
> > > Kind regards,
> > >
> > > Jonathan van Alteren
> > >
> > > Founding Member | Object Guild
> > > jvalte...@objectguild.com
> > > On 8 Oct 2019, 15:41 +0200, James Foster , wrote:
> > > >
> > > > > On Oct 8, 2019, at 3:05 AM, Jonathan van Alteren 
> > > > >  wrote:
> > > > >
> > > > > We've encountered an issue where a user makes changes to an agenda, 
> > > > > but does not click the Save button. Instead, the user closes the 
> > > > > browser or uses the navigation to go to a different part of the 
> > > > > application. When navigating back to the 

Re: [Pharo-users] voyage mongo and transactionality

[Jonathan van Alteren]

Hi James,

Thank you for your feedback.

If I remember correctly, in Java a persistence framework like JPA/Hibernate 
would track 'dirty' objects somehow and handle caching together with 
transaction management. There might be some things we might apply from those 
frameworks in Pharo/Smalltalk. However, our challenge is that we don't have 
much time to look at this because we need it to develop customer applications 
;-)

I will look into the Memento Pattern, thanks!


Kind regards,

Jonathan van Alteren

Founding Member | Object Guild
jvalte...@objectguild.com
On 9 Oct 2019, 16:26 +0200, James Foster , wrote:
> Thanks for the explanation. And, yes, this is an artifact of your design; if 
> you put intermediate values into domain objects then they will remain in your 
> domain objects to be seen later. From what you’ve described, I don’t see how 
> it would be any different in a non-image environment (Java, C#, etc.), unless 
> you re-read the entire object graph from the database. As someone else 
> mentioned, this would be a good place for the Memento Pattern.
>
> James
>
> > On Oct 9, 2019, at 1:59 AM, Jonathan van Alteren 
> >  wrote:
> >
> > Hi James,
> >
> > I see how my explanation might be unclear.
> >
> > We have a main form for the agenda and a subform for an item, which is 
> > shown using Seaside call/answer. The save button of the subform is clicked, 
> > which adds the item to the underlying agenda model object, but the save 
> > button of the main form is not clicked by the user. The callback for the 
> > main save button sends the save message to the agenda object, causing the 
> > database to be updated.
> >
> > So yes, the browser does submit the data on the subform, it's the main form 
> > component that doesn't receive the save button callback. I realize that 
> > this is in large part an issue with our design. However, the way object 
> > persistence seems to work in the image environment plays a large role.
> >
> >
> > Kind regards,
> >
> > Jonathan van Alteren
> >
> > Founding Member | Object Guild
> > jvalte...@objectguild.com
> > On 8 Oct 2019, 15:41 +0200, James Foster , wrote:
> > >
> > > > On Oct 8, 2019, at 3:05 AM, Jonathan van Alteren 
> > > >  wrote:
> > > >
> > > > We've encountered an issue where a user makes changes to an agenda, but 
> > > > does not click the Save button. Instead, the user closes the browser or 
> > > > uses the navigation to go to a different part of the application. When 
> > > > navigating back to the original agenda, the changes made previously 
> > > > (e.g. items added) are still being displayed, even though they were 
> > > > never explicitly saved.
> > >
> > > Here is what I don’t understand: how did the change get from the user’s 
> > > client agent (browser) to the server? If you make a change to a field in 
> > > a form and then close the browser, who sent the change to the server? If 
> > > you show the save domain value in a different location, with a 
> > > dynamically-generated id and name (so it isn’t cached in the browser), or 
> > > written to the Pharo Transcript, does the value still change? That is, 
> > > are you sure that the change is in the reflected in the Smalltalk image 
> > > and not just somehow cached in the browser?
> > >
> > > James
> > >
> > >
>

Re: [Pharo-users] voyage mongo and transactionality

[Jonathan van Alteren]

Hi Estaban,

Thanks for your feedback.

I agree that there might not be any real problem with Voyage. And yes, I think 
it was some kind of in-memory transaction handling that is was looking for.

Can you explain a bit more about how the cache in Voyage works and why it is 
the way it is?

The application in question doesn't have a lot of users, so changes are we 
could do without caching and still have good performance. I was used to working 
with JPA/Hibernate in Java, which doesn't seem to have the issue that we run 
into. Any idea why it works differently with Voyage/MongoDB? Is that because 
MongoDB doesn't support database transactions, hence missing a good trigger to 
flush the cache?

Making copies of domain model objects somehow 'feels wrong'. When I have a 
person in my CRM domain, I feel strongly that it should always ever be 
represented by 1 object instance of class Person.

The search continues... :-)


Kind regards,

Jonathan van Alteren

Founding Member | Object Guild
jvalte...@objectguild.com
On 8 Oct 2019, 12:54 +0200, Esteban Lorenzano , wrote:
> Hi,
>
> That looks a lot more like a Seaside mishandling than a problem with Voyage 
> itself.
>
> > On 8 Oct 2019, at 12:05, Jonathan van Alteren  
> > wrote:
> >
> > Hello all,
> >
> > We are having some issues with using Voyage/Mongo for a customer project 
> > that I'd like to get your feedback on.
> >
> > The customer application is a form based business web application using 
> > Seaside with object persistence using Voyage with MongoDB on Pharo 7.0. The 
> > application is deployed on a dedicated Linux production server running 
> > MongoDB version 4.2.
> >
> > The application is used to manage meeting agendas and minutes. After 
> > opening the agenda view of a future meeting, the user can add an item to 
> > the agenda by clicking a button. This calls an item editor component which 
> > answers when a Save or Cancel button is clicked. The agenda view component 
> > itself also has a Save button, which performs a Voyage save of the object 
> > aggregate (agenda + items).
> >
> > We've encountered an issue where a user makes changes to an agenda, but 
> > does not click the Save button. Instead, the user closes the browser or 
> > uses the navigation to go to a different part of the application. When 
> > navigating back to the original agenda, the changes made previously (e.g. 
> > items added) are still being displayed, even though they were never 
> > explicitly saved.
> >
> > It does not matter if we select the agenda aggregate object instance using 
> > Voyage or access it in a different way. Changes to the state of the object 
> > are retained, even though a Voyage save was never sent to the agenda 
> > instance. The cause seems to be that the Voyage repository caches the 
> > object instance and thus on select, it returns an object that is in a 
> > different state than how it was persisted.
> >
> > This all seems to come down to object transactionality.
> >
> > We have a need to 'cancel' changes made to an object instance. Before 
> > working with Pharo/Smalltalk in a non-image based environment, I was used 
> > to do this by retrieving the original object from persistence again. This 
> > also allowed for a convenient way to detect changes to an object's state, 
> > which we are missing at the moment too.
>
> In Voyage, new objects are just persisted (hence they enter the cache) once 
> you do the first “save”.
> Retrieved objects are indeed in the cache, and since there is just one copy 
> for Pharo instance, if you do an update of a property (even if you do not 
> save), the cached instance will have the new attribute value, since there is 
> no in-memory transaction handling in Voyage.
>
> Which means: you need to handle it by your self. One solution is to work on a 
> copy and on “save” flush the changes before (it is easy to develop methods to 
> automatise this).
>
> Well, something like that :)
>
> >
> > We know that moving to GemStone can help us with these issues, but our 
> > current planning of customer projects does not allow us to do this within 
> > the next 3 months. And we really need to find a way to tackle these issues .
>
> Well, not really, you will still need to copy modified values, retrieve new 
> and apply your changes.
> Of course if you want to discard possible in-memory changes, yes, you can 
> cancel the transaction in gemstone… and you can also re-read the object in 
> Voyage (no special api for that, even if we could add it… you need to 
> re-execute a query for it).
>
> Esteban
>
> >
> >
> > Your feedback is greatly appreciated!
> >
> >
> >
> > Kind regards,
> >
> >
> > Jonathan van Alteren
> >
> > Founding Member | Object Guild
> > jvalte...@objectguild.com
> >
>
>

Re: [Pharo-users] voyage mongo and transactionality

[Jonathan van Alteren]

Hi Norbert,

Thank you very much for your extensive answer.

For starters, we would be happy to have an option available for the course 
grained handling that you mention. I'd be interested to hear if there are any 
options besides GemStone available to be used with Voyage/MongoDB.

Your mention of the Mongo cache being a weak dictionary is very interesting, I 
did not know that (it doesn't seem to be documented). Yes, the Seaside sessions 
seem to be the path through which these objects remain referenced. When I 
inspect all instances of our session class, I see old session objects hanging 
around that still reference our root application component with the rendering 
tree containing various references to our domain model objects.

Can you tell me why the session objects don't get garbage collected?
Should we manually clean up our session object somehow?

I must admit I'm a bit out of my comfort zone here, after working in Java for 
close to 20 years ;-) We explicitly don't want to use any relational databases 
for our own application (perhaps only for integrating with customer data). I 
still haven't fully integrated the conceptual differences in my mental model, 
about how to work with objects in an image based/object persistence environment.

I did look into using a Voyage repository filter, which is mentioned (or buried 
deep I should say ;-)) in this post: 
https://pharoweekly.wordpress.com/2017/02/20/consortium-action-13-17-feb/. What 
if we were to use a dynamic variable like this for each session instance? Then 
at least each user will have her/his own cache. But that doesn't answer the 
need for a kind of rollback mechanism within the same Voyage cache/session. And 
then there is your comment about potentially having multiple copies of an 
identical object...

I wonder what patterns other Seaside 'enterprise' application developers are 
using.

You are right, the term object transactionality doesn't make much sense ;-) We 
are not using Magritte (and probably won't). I don't know much about Magritte, 
but it feels like it might be incompatible with the behavioral, 'pure' object 
approach that we want to use. However, I am interested to investigate. Can you 
recommend any good documentation sources for learning Magritte from an 
application architecture perspective?

Also, I'm interested to hear more about the modification tracking approach you 
are working on. Please drop me a personal note if you are willing to 
collaborate on this.


Kind regards,

Jonathan van Alteren

Founding Member | Object Guild
jvalte...@objectguild.com
On 8 Oct 2019, 12:54 +0200, Norbert Hartl , wrote:
> Hi,
>
> > Am 08.10.2019 um 12:05 schrieb Jonathan van Alteren 
> > :
> >
> > Hello all,
> >
> > We are having some issues with using Voyage/Mongo for a customer project 
> > that I'd like to get your feedback on.
> >
> > The customer application is a form based business web application using 
> > Seaside with object persistence using Voyage with MongoDB on Pharo 7.0. The 
> > application is deployed on a dedicated Linux production server running 
> > MongoDB version 4.2.
> >
> > The application is used to manage meeting agendas and minutes. After 
> > opening the agenda view of a future meeting, the user can add an item to 
> > the agenda by clicking a button. This calls an item editor component which 
> > answers when a Save or Cancel button is clicked. The agenda view component 
> > itself also has a Save button, which performs a Voyage save of the object 
> > aggregate (agenda + items).
> >
> > We've encountered an issue where a user makes changes to an agenda, but 
> > does not click the Save button. Instead, the user closes the browser or 
> > uses the navigation to go to a different part of the application. When 
> > navigating back to the original agenda, the changes made previously (e.g. 
> > items added) are still being displayed, even though they were never 
> > explicitly saved.
> >
> > It does not matter if we select the agenda aggregate object instance using 
> > Voyage or access it in a different way. Changes to the state of the object 
> > are retained, even though a Voyage save was never sent to the agenda 
> > instance. The cause seems to be that the Voyage repository caches the 
> > object instance and thus on select, it returns an object that is in a 
> > different state than how it was persisted.
> >
> > This all seems to come down to object transactionality.
> >
> > We have a need to 'cancel' changes made to an object instance. Before 
> > working with Pharo/Smalltalk in a non-image based environment, I was used 
> > to do this by retrieving the original object from persistence again. This 
> > also allowed for a convenient way to detect changes to an object's state, 
> > which we are missing at the moment too.
> >
> > We know that moving to GemStone can help us with these issues, but our 
> > current planning of customer projects does not allow us to do this within 
> > the next 3 months. And we 

Re: [Pharo-users] voyage mongo and transactionality

[PBKResearch]

It may be irrelevant, but I have been playing recently with OmniBase, which is 
a fully object-oriented database system, now over 20 years old, but it still 
works very well for my uses. David Gorišek, the author, claims that it has ACID 
properties. From my reading, updates operate on a proxy object, which is not 
written to the database until an explicit commit is given. A second transaction 
accessing the same object will still see the original until the change is 
committed. What happens to a proxy which is never committed is not clear, but 
if Gorišek is right, the stored data can never be contaminated. I think a proxy 
in this sense is equivalent to a memento.

 

Thanks to Esteban Lorenzano, OmniBase is now available on Pharo. The code is 
ancient, there is no documentation and obviously no support, but it might be 
worth while for someone to try some software archaeology and put it to use. I 
have found it possible to create and maintain a small database of natural 
language information, and access is fairly quick and easy – and it’s all 
Smalltalk.

It claims to store all kinds of Smalltalk objects, except block closures, and 
skimming through the code it seems to incorporate a serializer similar to Fuel.

 

The only documentation I have found is a slideshow at 
https://www.slideshare.net/esug/omni-baseobjectdatabase. I have found out a few 
things about it, if anyone is interested.

 

Peter Kenny

 

 

From: Pharo-users  On Behalf Of Norbert 
Hartl
Sent: 09 October 2019 18:08
To: Any question about pharo is welcome 
Subject: Re: [Pharo-users] voyage mongo and transactionality

 

 


Am 09.10.2019 um 16:48 schrieb "jtuc...@objektfabrik.de 
<mailto:jtuc...@objektfabrik.de> " mailto:jtuc...@objektfabrik.de> >:

 

This is a tricky mine field. Sometimes you need a lot of business functionality 
in objects referenced in your objects that are currently in the editor. So I'm 
still to see a project in which the memento pattern really worked for more 
complex scenarios. How deep do you dive to have enough memento objects to 
provide the functionality needed. I guess you can do that with some sort of 
object-level transaction framework that automatically creates mementos of 
whatever object is being navigated to during some kind of processing-context. I 
guess slots could be of use here. But this is not trivial for general cases.

 

Yes it is tricky. You can have copies of business objects but you have always 
references to the business objects not pointing to the copy. 

And you need to know which objects should be tracked. In Gemstone IIRC it is 
easy as it is the time the object is copied from the stone to the gem it is 
registered in the current transaction. So you can check it and committing if it 
changed because you have to write it back. The important point here might be 
get noticed when a reference is acquired. In pharo it is not that easy but 
could be done if object would be reified and interceptable. 

In my experience, this problem area makes for the other 70% of the time spent 
on developing GUI or Web applications, besides the 60% for GUI design and 
implementation and 25% business logic...

70% + 60% + 25% + 30% = 185%

 

sounds indeed very realistic if it comes to project planning. There is even a 
rule saying that for the first 90% of the project you need the first 90% of 
time and for the last 10% of the project you need the second 90% of time. 



I'd be interested to learn about patterns to handle such more complex things. 
We constantly travel back and forth between implementing stuff in the GUI 
handlers (copying values to the GUI classes that access themselves during GUI 
operations and push values to the business objects when the users clicks on 
OK), using mementos (which most of the times are nets of mementos that are 
created manually - "we know what we'll touch in this Editor") and operating on 
business objects directly and relying on the persistence mechanism (Glorp in 
our case) and its rollback behaviour. All three have lots of weaknesses and 
seem to have their place nevertheless.

So this is a very interesting discussion and I think this is an area that has 
not been solved yet.

I think it isn‘t solved and I find every piece of information about it very 
interesting.

 

Norbert



Joachim

 

 

 

 

 

 

Am 09.10.19 um 16:25 schrieb James Foster:

Thanks for the explanation. And, yes, this is an artifact of your design; if 
you put intermediate values into domain objects then they will remain in your 
domain objects to be seen later. From what you’ve described, I don’t see how it 
would be any different in a non-image environment (Java, C#, etc.), unless you 
re-read the entire object graph from the database. As someone else mentioned, 
this would be a good place for the Memento Pattern. 

 

James





On Oct 9, 2019, at 1:59 AM, Jonathan van Alteren mailto:jvalte...@objectguild.com> > wrote:

 

Hi James, 

 

I s

Re: [Pharo-users] voyage mongo and transactionality

[Norbert Hartl]

> Am 09.10.2019 um 16:48 schrieb "jtuc...@objektfabrik.de" 
> :
> 
> 
> This is a tricky mine field. Sometimes you need a lot of business 
> functionality in objects referenced in your objects that are currently in the 
> editor. So I'm still to see a project in which the memento pattern really 
> worked for more complex scenarios. How deep do you dive to have enough 
> memento objects to provide the functionality needed. I guess you can do that 
> with some sort of object-level transaction framework that automatically 
> creates mementos of whatever object is being navigated to during some kind of 
> processing-context. I guess slots could be of use here. But this is not 
> trivial for general cases.

Yes it is tricky. You can have copies of business objects but you have always 
references to the business objects not pointing to the copy. 
And you need to know which objects should be tracked. In Gemstone IIRC it is 
easy as it is the time the object is copied from the stone to the gem it is 
registered in the current transaction. So you can check it and committing if it 
changed because you have to write it back. The important point here might be 
get noticed when a reference is acquired. In pharo it is not that easy but 
could be done if object would be reified and interceptable. 
> In my experience, this problem area makes for the other 70% of the time spent 
> on developing GUI or Web applications, besides the 60% for GUI design and 
> implementation and 25% business logic...
> 
70% + 60% + 25% + 30% = 185%

sounds indeed very realistic if it comes to project planning. There is even a 
rule saying that for the first 90% of the project you need the first 90% of 
time and for the last 10% of the project you need the second 90% of time. 
> I'd be interested to learn about patterns to handle such more complex things. 
> We constantly travel back and forth between implementing stuff in the GUI 
> handlers (copying values to the GUI classes that access themselves during GUI 
> operations and push values to the business objects when the users clicks on 
> OK), using mementos (which most of the times are nets of mementos that are 
> created manually - "we know what we'll touch in this Editor") and operating 
> on business objects directly and relying on the persistence mechanism (Glorp 
> in our case) and its rollback   behaviour. All three have lots of 
> weaknesses and seem to have their place nevertheless.
> 
> So this is a very interesting discussion and I think this is an area that has 
> not been solved yet.
> 
I think it isn‘t solved and I find every piece of information about it very 
interesting.

Norbert
> Joachim
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>> Am 09.10.19 um 16:25 schrieb James Foster:
>> Thanks for the explanation. And, yes, this is an artifact of your design; if 
>> you put intermediate values into domain objects then they will remain in 
>> your domain objects to be seen later. From what you’ve described, I don’t 
>> see how it would be any different in a non-image environment (Java, C#, 
>> etc.), unless you re-read the entire object graph from the database. As 
>> someone else mentioned, this would be a good place for the Memento Pattern.
>> 
>> James
>> 
>>> On Oct 9, 2019, at 1:59 AM, Jonathan van Alteren 
>>>  wrote:
>>> 
>>> Hi James,
>>> 
>>> I see how my explanation might be unclear.
>>> 
>>> We have a main form for the agenda and a subform for an item, which is 
>>> shown using Seaside call/answer. The save button of the subform is clicked, 
>>> which adds the item to the underlying agenda model object, but the save 
>>> button of the main form is not clicked by the user. The callback for the 
>>> main save button sends the save message to the agenda object, causing the 
>>> database to be updated.
>>> 
>>> So yes, the browser does submit the data on the subform, it's the main form 
>>> component that doesn't receive the save button callback. I realize that 
>>> this is in large part an issue with our design. However, the way object 
>>> persistence seems to work in the image environment plays a large role. 
>>> 
>>> 
>>> Kind regards,
>>> 
>>> Jonathan van Alteren
>>> 
>>> Founding Member | Object Guild
>>> jvalte...@objectguild.com
 On 8 Oct 2019, 15:41 +0200, James Foster , wrote:
 
> On Oct 8, 2019, at 3:05 AM, Jonathan van Alteren 
>  wrote:
> 
> We've encountered an issue where a user makes changes to an agenda, but 
> does not click the Save button. Instead, the user closes the browser or 
> uses the navigation to go to a different part of the application. When 
> navigating back to the original agenda, the changes made previously (e.g. 
>   items added) are still being displayed, even
>though they were never explicitly saved.
 
 Here is what I don’t understand: how did the change get from the user’s 
 client agent (browser) to the server? If you make a change to a 

Re: [Pharo-users] voyage mongo and transactionality

[jtuc...@objektfabrik.de]

Am 09.10.19 um 16:48 schrieb jtuc...@objektfabrik.de:


In my experience, this problem area makes for the other 70% of the 
time spent on developing GUI or Web applications, besides the 60% for 
GUI design and implementation and 25% business logic...



I forgot the 30% for O/R Mapping when you use an ORM ;-)


Joachim


--
---
Objektfabrik Joachim Tuchel  mailto:jtuc...@objektfabrik.de
Fliederweg 1 http://www.objektfabrik.de
D-71640 Ludwigsburg  http://joachimtuchel.wordpress.com
Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1

Re: [Pharo-users] voyage mongo and transactionality

[jtuc...@objektfabrik.de]

This is a tricky mine field. Sometimes you need a lot of business 
functionality in objects referenced in your objects that are currently 
in the editor. So I'm still to see a project in which the memento 
pattern really worked for more complex scenarios. How deep do you dive 
to have enough memento objects to provide the functionality needed. I 
guess you can do that with some sort of object-level transaction 
framework that automatically creates mementos of whatever object is 
being navigated to during some kind of processing-context. I guess slots 
could be of use here. But this is not trivial for general cases.


In my experience, this problem area makes for the other 70% of the time 
spent on developing GUI or Web applications, besides the 60% for GUI 
design and implementation and 25% business logic...


I'd be interested to learn about patterns to handle such more complex 
things. We constantly travel back and forth between implementing stuff 
in the GUI handlers (copying values to the GUI classes that access 
themselves during GUI operations and push values to the business objects 
when the users clicks on OK), using mementos (which most of the times 
are nets of mementos that are created manually - "we know what we'll 
touch in this Editor") and operating on business objects directly and 
relying on the persistence mechanism (Glorp in our case) and its 
rollback behaviour. All three have lots of weaknesses and seem to have 
their place nevertheless.


So this is a very interesting discussion and I think this is an area 
that has not been solved yet.



Joachim







Am 09.10.19 um 16:25 schrieb James Foster:
Thanks for the explanation. And, yes, this is an artifact of your 
design; if you put intermediate values into domain objects then they 
will remain in your domain objects to be seen later. From what you’ve 
described, I don’t see how it would be any different in a non-image 
environment (Java, C#, etc.), unless you re-read the entire object 
graph from the database. As someone else mentioned, this would be a 
good place for the Memento Pattern.


James

On Oct 9, 2019, at 1:59 AM, Jonathan van Alteren 
mailto:jvalte...@objectguild.com>> wrote:


Hi James,

I see how my explanation might be unclear.

We have a main form for the agenda and a subform for an item, which 
is shown using Seaside call/answer. The save button of the subform is 
clicked, which adds the item to the underlying agenda model object, 
but the save button of the main form _is not_ clicked by the user. 
The callback for the main save button sends the save message to the 
agenda object, causing the database to be updated.


So yes, the browser does submit the data on the subform, it's the 
main form component that doesn't receive the save button callback. I 
realize that this is in large part an issue with our design. However, 
the way object persistence seems to work in the image environment 
plays a large role.



Kind regards,

Jonathan van Alteren

Founding Member | Object Guild
jvalte...@objectguild.com 
On 8 Oct 2019, 15:41 +0200, James Foster >, wrote:


On Oct 8, 2019, at 3:05 AM, Jonathan van Alteren 
mailto:jvalte...@objectguild.com>> wrote:


We've encountered an issue where a user makes changes to an agenda, 
but does not click the Save button. Instead, the user closes the 
browser or uses the navigation to go to a different part of the 
application. When navigating back to the original agenda, the 
changes made previously (e.g. items added) are still being 
displayed, even though they were never explicitly saved.


Here is what I don’t understand: how did the change get from the 
user’s client agent (browser) to the server? If you make a change to 
a field in a form and then close the browser, who sent the change to 
the server? If you show the save domain value in a different 
location, with a dynamically-generated id and name (so it isn’t 
cached in the browser), or written to the Pharo Transcript, does the 
value still change? That is, are you sure that the change is in the 
reflected in the Smalltalk image and not just somehow cached in the 
browser?


James






--
---
Objektfabrik Joachim Tuchel  mailto:jtuc...@objektfabrik.de
Fliederweg 1 http://www.objektfabrik.de
D-71640 Ludwigsburg  http://joachimtuchel.wordpress.com
Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1

Re: [Pharo-users] voyage mongo and transactionality

[James Foster]

Thanks for the explanation. And, yes, this is an artifact of your design; if 
you put intermediate values into domain objects then they will remain in your 
domain objects to be seen later. From what you’ve described, I don’t see how it 
would be any different in a non-image environment (Java, C#, etc.), unless you 
re-read the entire object graph from the database. As someone else mentioned, 
this would be a good place for the Memento Pattern.

James

> On Oct 9, 2019, at 1:59 AM, Jonathan van Alteren  
> wrote:
> 
> Hi James,
> 
> I see how my explanation might be unclear.
> 
> We have a main form for the agenda and a subform for an item, which is shown 
> using Seaside call/answer. The save button of the subform is clicked, which 
> adds the item to the underlying agenda model object, but the save button of 
> the main form is not clicked by the user. The callback for the main save 
> button sends the save message to the agenda object, causing the database to 
> be updated.
> 
> So yes, the browser does submit the data on the subform, it's the main form 
> component that doesn't receive the save button callback. I realize that this 
> is in large part an issue with our design. However, the way object 
> persistence seems to work in the image environment plays a large role. 
> 
> 
> Kind regards,
> 
> Jonathan van Alteren
> 
> Founding Member | Object Guild
> jvalte...@objectguild.com
> On 8 Oct 2019, 15:41 +0200, James Foster , wrote:
>> 
>>> On Oct 8, 2019, at 3:05 AM, Jonathan van Alteren 
>>>  wrote:
>>> 
>>> We've encountered an issue where a user makes changes to an agenda, but 
>>> does not click the Save button. Instead, the user closes the browser or 
>>> uses the navigation to go to a different part of the application. When 
>>> navigating back to the original agenda, the changes made previously (e.g. 
>>> items added) are still being displayed, even though they were never 
>>> explicitly saved.
>> 
>> Here is what I don’t understand: how did the change get from the user’s 
>> client agent (browser) to the server? If you make a change to a field in a 
>> form and then close the browser, who sent the change to the server? If you 
>> show the save domain value in a different location, with a 
>> dynamically-generated id and name (so it isn’t cached in the browser), or 
>> written to the Pharo Transcript, does the value still change? That is, are 
>> you sure that the change is in the reflected in the Smalltalk image and not 
>> just somehow cached in the browser?
>> 
>> James
>> 
>> 

Re: [Pharo-users] voyage mongo and transactionality

[Jonathan van Alteren]

Hi James,

I see how my explanation might be unclear.

We have a main form for the agenda and a subform for an item, which is shown 
using Seaside call/answer. The save button of the subform is clicked, which 
adds the item to the underlying agenda model object, but the save button of the 
main form is not clicked by the user. The callback for the main save button 
sends the save message to the agenda object, causing the database to be updated.

So yes, the browser does submit the data on the subform, it's the main form 
component that doesn't receive the save button callback. I realize that this is 
in large part an issue with our design. However, the way object persistence 
seems to work in the image environment plays a large role.


Kind regards,

Jonathan van Alteren

Founding Member | Object Guild
jvalte...@objectguild.com
On 8 Oct 2019, 15:41 +0200, James Foster , wrote:
>
> > On Oct 8, 2019, at 3:05 AM, Jonathan van Alteren 
> >  wrote:
> >
> > We've encountered an issue where a user makes changes to an agenda, but 
> > does not click the Save button. Instead, the user closes the browser or 
> > uses the navigation to go to a different part of the application. When 
> > navigating back to the original agenda, the changes made previously (e.g. 
> > items added) are still being displayed, even though they were never 
> > explicitly saved.
>
> Here is what I don’t understand: how did the change get from the user’s 
> client agent (browser) to the server? If you make a change to a field in a 
> form and then close the browser, who sent the change to the server? If you 
> show the save domain value in a different location, with a 
> dynamically-generated id and name (so it isn’t cached in the browser), or 
> written to the Pharo Transcript, does the value still change? That is, are 
> you sure that the change is in the reflected in the Smalltalk image and not 
> just somehow cached in the browser?
>
> James
>
>

Re: [Pharo-users] voyage mongo and transactionality

[James Foster]

> On Oct 8, 2019, at 3:05 AM, Jonathan van Alteren  
> wrote:
> 
> We've encountered an issue where a user makes changes to an agenda, but does 
> not click the Save button. Instead, the user closes the browser or uses the 
> navigation to go to a different part of the application. When navigating back 
> to the original agenda, the changes made previously (e.g. items added) are 
> still being displayed, even though they were never explicitly saved.

Here is what I don’t understand: how did the change get from the user’s client 
agent (browser) to the server? If you make a change to a field in a form and 
then close the browser, who sent the change to the server? If you show the save 
domain value in a different location, with a dynamically-generated id and name 
(so it isn’t cached in the browser), or written to the Pharo Transcript, does 
the value still change? That is, are you sure that the change is in the 
reflected in the Smalltalk image and not just somehow cached in the browser?

James

Re: [Pharo-users] voyage mongo and transactionality

[Norbert Hartl]

Hi,

> Am 08.10.2019 um 12:05 schrieb Jonathan van Alteren 
> :
> 
> Hello all,
> 
> We are having some issues with using Voyage/Mongo for a customer project that 
> I'd like to get your feedback on. 
> 
> The customer application is a form based business web application using 
> Seaside with object persistence using Voyage with MongoDB on Pharo 7.0. The 
> application is deployed on a dedicated Linux production server running 
> MongoDB version 4.2.
> 
> The application is used to manage meeting agendas and minutes. After opening 
> the agenda view of a future meeting, the user can add an item to the agenda 
> by clicking a button. This calls an item editor component which answers when 
> a Save or Cancel button is clicked. The agenda view component itself also has 
> a Save button, which performs a Voyage save of the object aggregate (agenda + 
> items).
> 
> We've encountered an issue where a user makes changes to an agenda, but does 
> not click the Save button. Instead, the user closes the browser or uses the 
> navigation to go to a different part of the application. When navigating back 
> to the original agenda, the changes made previously (e.g. items added) are 
> still being displayed, even though they were never explicitly saved.
> 
> It does not matter if we select the agenda aggregate object instance using 
> Voyage or access it in a different way. Changes to the state of the object 
> are retained, even though a Voyage save was never sent to the agenda 
> instance. The cause seems to be that the Voyage repository caches the object 
> instance and thus on select, it returns an object that is in a different 
> state than how it was persisted.
> 
> This all seems to come down to object transactionality. 
> 
> We have a need to 'cancel' changes made to an object instance. Before working 
> with Pharo/Smalltalk in a non-image based environment, I was used to do this 
> by retrieving the original object from persistence again. This also allowed 
> for a convenient way to detect changes to an object's state, which we are 
> missing at the moment too.
> 
> We know that moving to GemStone can help us with these issues, but our 
> current planning of customer projects does not allow us to do this within the 
> next 3 months. And we really need to find a way to tackle these issues .
> 
> 
> Your feedback is greatly appreciated!
> 
this is none to be confusing to a lot of people. If you map a memory object 
graph to a database there are no intrinsic points of transactions unless you 
put them into your application model. Gemstone or any transaction based 
handling won‘t help you if your use case is not as coarse grained as discarding 
all modified data and not just some. Or you need to hop into nested 
transactions which are supported by Gemstone IMHO but there is rules to care 
about, too, if you want to use them.

Regarding your application you modify data and this is kept. The cache in mongo 
is a weak dictionary. This means that if you get the object with the changes a 
second time it means these objects are referenced somewhere. Seaside sessions 
seems to be the obvious thing here. If you have a reachable object (e.g. server 
singleton -> handler -> seaside -> seaside session -> business object) then 
mongo keeps the object in its cache because it needs to be able to establish 
identity on further queries. Ein emoving all the changes from an object you 
keep in memory wouldn‘t be really good if the persistence layer would do it. 

The problem is obvious but the solution is not. We could make the cache session 
or request based which would circumvent the problem. But if an object would be 
attached to something outside the session/request which you cannot forbid it 
causes real problems like multiple copies to an identical object.

I don‘t know what you mean with object transactionality because it makes no 
sense in my head. But you have basically two approaches to solve the problem. 
If you would use magritte you would have it at hand. There each UI component 
gets just a memento of the business object for modification. You need to commit 
the UI component in order to modify the business object. So you can commit on 
user interaction and separately on persistence which allows a huge set of use 
cases.
The other one I‘m working on since a while is a proper modification tracking. 
In this you change the objects directly but have a registry with the dirty 
objects which you can act upon. I have a sample modification tracker that uses 
readOnly object write barrier for objects. On write attempt it registers the 
object and the write operation as command pattern. You can undo modifications 
of a single object where all commmands are undone on that object. Or you abort 
all modifications at once. It is basically working but has the problems on 
concurrent access. As the mongo cache is image wide two concurrent requests 
interfere with each other.
So you can see that the problem is not that easy to solve.

Re: [Pharo-users] voyage mongo and transactionality

[Esteban Lorenzano]

Hi, 

That looks a lot more like a Seaside mishandling than a problem with Voyage 
itself. 

> On 8 Oct 2019, at 12:05, Jonathan van Alteren  
> wrote:
> 
> Hello all,
> 
> We are having some issues with using Voyage/Mongo for a customer project that 
> I'd like to get your feedback on. 
> 
> The customer application is a form based business web application using 
> Seaside with object persistence using Voyage with MongoDB on Pharo 7.0. The 
> application is deployed on a dedicated Linux production server running 
> MongoDB version 4.2.
> 
> The application is used to manage meeting agendas and minutes. After opening 
> the agenda view of a future meeting, the user can add an item to the agenda 
> by clicking a button. This calls an item editor component which answers when 
> a Save or Cancel button is clicked. The agenda view component itself also has 
> a Save button, which performs a Voyage save of the object aggregate (agenda + 
> items).
> 
> We've encountered an issue where a user makes changes to an agenda, but does 
> not click the Save button. Instead, the user closes the browser or uses the 
> navigation to go to a different part of the application. When navigating back 
> to the original agenda, the changes made previously (e.g. items added) are 
> still being displayed, even though they were never explicitly saved.
> 
> It does not matter if we select the agenda aggregate object instance using 
> Voyage or access it in a different way. Changes to the state of the object 
> are retained, even though a Voyage save was never sent to the agenda 
> instance. The cause seems to be that the Voyage repository caches the object 
> instance and thus on select, it returns an object that is in a different 
> state than how it was persisted.
> 
> This all seems to come down to object transactionality. 
> 
> We have a need to 'cancel' changes made to an object instance. Before working 
> with Pharo/Smalltalk in a non-image based environment, I was used to do this 
> by retrieving the original object from persistence again. This also allowed 
> for a convenient way to detect changes to an object's state, which we are 
> missing at the moment too.

In Voyage, new objects are just persisted (hence they enter the cache) once you 
do the first “save”. 
Retrieved objects are indeed in the cache, and since there is just one copy for 
Pharo instance, if you do an update of a property (even if you do not save), 
the cached instance will have the new attribute value, since there is no 
in-memory transaction handling in Voyage.

Which means: you need to handle it by your self. One solution is to work on a 
copy and on “save” flush the changes before (it is easy to develop methods to 
automatise this). 

Well, something like that :)

> 
> We know that moving to GemStone can help us with these issues, but our 
> current planning of customer projects does not allow us to do this within the 
> next 3 months. And we really need to find a way to tackle these issues .

Well, not really, you will still need to copy modified values, retrieve new and 
apply your changes. 
Of course if you want to discard possible in-memory changes, yes, you can 
cancel the transaction in gemstone… and you can also re-read the object in 
Voyage (no special api for that, even if we could add it… you need to 
re-execute a query for it).

Esteban

> 
> 
> Your feedback is greatly appreciated!
> 
> 
> 
> Kind regards,
> 
> 
> Jonathan van Alteren
> 
> Founding Member | Object Guild
> jvalte...@objectguild.com
> 

Re: [Pharo-users] Voyage for Pharo 7

[Roelof Wobben]

  
  
I succeeded in doing it this way 
  
  1) make on the root of the disk a seperate directory for example
  c:/repo 
  
  2) on the settings goto tools -> software configuration
  management -> iceberg and check share repo and point it to the
  repo you made on point 1 
  
  3) make this baseline : 
  
  
  'From Pharo7.0.1 of 6 February 2019 [Build information:
  Pharo-7.0.1+build.148.sha.442fd72baccda88a9a3a72fe8158ebb31bf1b67a
  (64 Bit)] on 24 February 2019 at 12:21:40.555764 pm'!
  BaselineOf subclass: #BaselineOfRoelof
      instanceVariableNames: ''
      classVariableNames: ''
      poolDictionaries: ''
      category: 'BaselineOfRoelof'!
  
  !BaselineOfRoelof methodsFor: 'baseline' stamp: 'SabineMa
  2/24/2019 12:17'!
  voyage: spec
      spec
          baseline: 'Voyage'
          with: [ spec repository:
  'github://pharo-nosql/voyage:ef3e6aa/mc' ]! !
  
  !BaselineOfRoelof methodsFor: 'baseline' stamp: 'SabineMa
  2/24/2019 12:16'!
  baseline: spec
      
      spec
          for: #common
          do: [ spec blessing: #baseline.
              self
               voyage: spec ]! !
  
  
  4) run this script on playground : 
  
  Metacello new
  onWarning: [ :ex | Transcript crShow: ex ];
  onConflict: [ :ex | Transcript crShow: ex. ex useIncoming ];
  onUpgrade: [ :ex | Transcript crShow: ex. ex useIncoming ];
  onDowngrade: [ :ex | Transcript crShow: ex. ex useLoaded ];
  onLock:[ :ex | Transcript crShow: ex. ];
  ignoreImage; baseline: 'Roelof'; load.
  
  
  
  Roelof
  
  
  
  
  Op 26-2-2019 om 17:18 schreef sergio ruiz:


  
  
  Is the
installation for this set up somewhere? 
  
  
  I am using
the metacello script here:
  
  
  https://github.com/pharo-nosql/voyage
  
  
  and the
catalog..
  
  
  and am
getting errors everywhere.
  
  
  Thanks!
  
  
  
  

  peace,
  sergio
  photographer, journalist, visionary


Public
  Key: http://bit.ly/29z9fG0
  #BitMessage BM-NBaswViL21xqgg9STRJjaJaUoyiNe2dV
  http://www.codeandmusic.com
  http://www.twitter.com/sergio_101
  http://www.facebook.com/sergio101
  


  

Re: [Pharo-users] Voyage

[Sanjay Minni]

This seems to work - at least loading seems to have gone thru

but is it possible to shorten the following filename in the github
repository itself

cryptUIDlgSelectCertificateFromStore.winHandle.pwszTitle.pwszDisplayString.dwDontUseColumn.flags.reserved..st

it is in
https://github.com/pharo-contributions/Cryptography/tree/master/source/Cryptography-MSCerts.package/Win32FFICertificateStore.class/instance

i do not know if there any any other filenames that long


EstebanLM wrote
> Hi, 
> 
> I’m sorry I didn’t see this before. 
> This happens because there are many projects that are still using filetree
> format which stores one file per method. And the problem here is that
> windows has a path limit that you are exceeding. 
> To workaround this problem: 
> 
> - Open iceberg settings (toolbar button in repositories window).
> - Check "Share repositories between images”.
> - In "Location for shared repositories” put something like “C:\repo” (you
> will need to create that dir too).
> 
> And retry :)
> 
> Esteban
> 
>> On 4 Dec 2018, at 17:24, Sanjay Minni 

> sm@

>  wrote:
>> 
>> Hi Esteban,
>> 
>> I get a Debug Popup as per below - how do I debug from here
>> 
>> http://forum.world.st/file/t368721/VoyageIcebergLoadErr01.jpg
>> http://forum.world.st/file/t368721/VoyageIcebergLoadErr01.jpg;> 
>> 
>> http://forum.world.st/file/t368721/VoyageLoadError01.jpg
>> http://forum.world.st/file/t368721/VoyageLoadError01.jpg;> 
>> 
>> 
>> EstebanLM wrote
>>> There is indeed a problem because cryptography package is still using an
>>> old API: #ifNotNilDo: that does not exists anymore in Pharo. 
>>> You are probably seen something like this: 
>>> 
>>> 
>>> 
>>> 
>>> (And this is a bug)
>>> Anyway, while we fix this, you can replace #ifNotNilDo: for #ifNotNil:,
>>> then save and select “proceed”.
>>> 
>>> That will allow voyage to load properly.
>>> 
>>> Cheers, 
>>> Esteban
>>> 
>>> 
>>> 
 On 2 Dec 2018, at 12:39, Sanjay Minni 
>> 
>>> sm@
>> 
>>>  wrote:
 
 I am unable to load Voyage-Mongo and Voyage-Memory in  Pharo 7.0.0rC1
 
 tried using the scipt below and also thru the Catalog Browser entries
 for
 Voyage
 any pointers
 
 
 CyrilFerlicot wrote
> Le 16/11/2018 à 02:02, horrido a écrit :
>> I'm trying to load Voyage for MongoDB and I'm having great
>> difficulty.
>> The
>> docs seem to be out of date.
>> 
>> What are the current instructions for doing this?
>> 
>> The docs also refer to "Configurations Browser" in World Menu/Tools,
>> but
>> there is no longer any such thing.
>> 
>> 
> 
> Hi,
> 
> Voyage-Mongo
> 
> Metacello new
>   repository: 'github://pharo-nosql/voyage/mc';
>   baseline: 'Voyage';
>   onConflictUseIncoming;
>   load: 'mongo tests'.
> 
> Voyage-UnQLite
> 
> Metacello new
>   repository: 'github://pharo-nosql/voyage/mc';
>   baseline: 'Voyage';
>   onConflictUseIncoming;
>   load: 'unqlite tests'.
> 
> Voyage-Memory
> 
> Metacello new
>   repository: 'github://pharo-nosql/voyage/mc';
>   baseline: 'Voyage';
>   onConflictUseIncoming;
>   load: 'memory tests'.
> 
> Should work.
> 
>> 
>> --
>> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
>> 
> 
> 
> -- 
> Cyril Ferlicot
> https://ferlicot.fr
> 
> 
> 
> signature.asc (836 bytes)
> http://forum.world.st/attachment/5088985/0/signature.asc;
 
 
 
 
 
 -
 cheers, 
 Sanjay
 --
 Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
 
>>> 
>>> 
>>> 
>>> Screenshot 2018-12-02 at 15.02.19.png (165K)
>>> http://forum.world.st/attachment/5090021/0/Screenshot%202018-12-02%20at%2015.02.19.png
>>> http://forum.world.st/attachment/5090021/0/Screenshot%202018-12-02%20at%2015.02.19.pnggt;;
>> 
>> 
>> 
>> 
>> 
>> -
>> cheers, 
>> Sanjay
>> --
>> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
>> http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html;





-
cheers, 
Sanjay
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Re: [Pharo-users] Voyage

[Esteban Lorenzano]

Hi, 

I’m sorry I didn’t see this before. 
This happens because there are many projects that are still using filetree 
format which stores one file per method. And the problem here is that windows 
has a path limit that you are exceeding. 
To workaround this problem: 

- Open iceberg settings (toolbar button in repositories window).
- Check "Share repositories between images”.
- In "Location for shared repositories” put something like “C:\repo” (you will 
need to create that dir too).

And retry :)

Esteban

> On 4 Dec 2018, at 17:24, Sanjay Minni  wrote:
> 
> Hi Esteban,
> 
> I get a Debug Popup as per below - how do I debug from here
> 
>  > 
> 
>  > 
> 
> 
> EstebanLM wrote
>> There is indeed a problem because cryptography package is still using an
>> old API: #ifNotNilDo: that does not exists anymore in Pharo. 
>> You are probably seen something like this: 
>> 
>> 
>> 
>> 
>> (And this is a bug)
>> Anyway, while we fix this, you can replace #ifNotNilDo: for #ifNotNil:,
>> then save and select “proceed”.
>> 
>> That will allow voyage to load properly.
>> 
>> Cheers, 
>> Esteban
>> 
>> 
>> 
>>> On 2 Dec 2018, at 12:39, Sanjay Minni 
> 
>> sm@
> 
>>  wrote:
>>> 
>>> I am unable to load Voyage-Mongo and Voyage-Memory in  Pharo 7.0.0rC1
>>> 
>>> tried using the scipt below and also thru the Catalog Browser entries for
>>> Voyage
>>> any pointers
>>> 
>>> 
>>> CyrilFerlicot wrote
 Le 16/11/2018 à 02:02, horrido a écrit :
> I'm trying to load Voyage for MongoDB and I'm having great difficulty.
> The
> docs seem to be out of date.
> 
> What are the current instructions for doing this?
> 
> The docs also refer to "Configurations Browser" in World Menu/Tools,
> but
> there is no longer any such thing.
> 
> 
 
 Hi,
 
 Voyage-Mongo
 
 Metacello new
   repository: 'github://pharo-nosql/voyage/mc';
   baseline: 'Voyage';
   onConflictUseIncoming;
   load: 'mongo tests'.
 
 Voyage-UnQLite
 
 Metacello new
   repository: 'github://pharo-nosql/voyage/mc';
   baseline: 'Voyage';
   onConflictUseIncoming;
   load: 'unqlite tests'.
 
 Voyage-Memory
 
 Metacello new
   repository: 'github://pharo-nosql/voyage/mc';
   baseline: 'Voyage';
   onConflictUseIncoming;
   load: 'memory tests'.
 
 Should work.
 
> 
> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
> 
 
 
 -- 
 Cyril Ferlicot
 https://ferlicot.fr
 
 
 
 signature.asc (836 bytes)
 http://forum.world.st/attachment/5088985/0/signature.asc;
>>> 
>>> 
>>> 
>>> 
>>> 
>>> -
>>> cheers, 
>>> Sanjay
>>> --
>>> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
>>> 
>> 
>> 
>> 
>> Screenshot 2018-12-02 at 15.02.19.png (165K)
>> http://forum.world.st/attachment/5090021/0/Screenshot%202018-12-02%20at%2015.02.19.png
>>  
>> ;
> 
> 
> 
> 
> 
> -
> cheers, 
> Sanjay
> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html 
> 

Re: [Pharo-users] Voyage

[Ben Coman]

Second thing to try, is copy the VM and Image
into a short path location e.g C:\pharo
Then try your Pharo actions again.

As backup, you might use these...
http://files.pharo.org/get-files/70/pharo.zip
http://files.pharo.org/get-files/70/pharo-win-stable.zip

cheers -ben

On Fri, 7 Dec 2018 at 17:39, Sanjay Minni  wrote:

> I can download the file and shorten the name but the issue is it seems that
> the process stops and remaining files and not downloaded, how to get around
> that ?
>
> to elaborate - only the first 7 files of this folder is copied/downloaded
> into pharo-local/...
>
>
> https://github.com/pharo-contributions/Cryptography/tree/master/source/Cryptography-MSCerts.package/Win32FFICertificateStore.class/instance
>
>
>
> Ben Coman wrote
> > On Fri, 7 Dec 2018 at 00:26, Sanjay Minni 
>
> > sm@
>
> >  wrote:
> >
> >> Hi Ben,
> >>
> >> how to go about the hack ?
> >>
> >> it seems the file being looked for is this(from the github Cryptography
> >> repository)
> >> http://forum.world.st/file/t368721/CryptographyLoadErr.jpg;
> >>
> > but this is not copied in ...\pharo-local\...\sources\...
> >> http://forum.world.st/file/t368721/CryptographyFilesInSource.jpg
> ;
> >>
> >>
> > Try manually downloading that file and put it in place named something
> > short like e.g. "xx.st"
> >  I'm not certain that will work, but worth a try.
> >
> > Alternatively, install pharo in a short root folder "C:\x" to give it
> > filenames plenty of headroom.
> > Note, this might not be your problem, but should help scope it out.
> >
> >
> >
> >> also
> >> Voyage loading thru playground ultimately terminates as per screen below
> >> (is
> >> this an expected behaviour) ?
> >> http://forum.world.st/file/t368721/VoyageLoadTermination.jpg;
> >>
> >>
> >  I'm  not familiar with that.
> >
> > cheers -ben
> >
> >
> >>
> >>
> >> Ben Coman wrote
> >> > On Wed, 5 Dec 2018 at 00:25, Sanjay Minni 
> >>
> >> > sm@
> >>
> >> >  wrote:
> >> >
> >> >> Hi Esteban,
> >> >>
> >> >> I get a Debug Popup as per below - how do I debug from here
> >> >>
> >> >> http://forum.world.st/file/t368721/VoyageIcebergLoadErr01.jpg
> ;
> >> >>
> >> >> http://forum.world.st/file/t368721/VoyageLoadError01.jpg;
> >> >>
> >> >
> >> > Is this on Windows?
> >> > It could be that long path names continue to bite.
> >> > Could you try a hack... go in on the command line and shorten the
> >> > directory
> >> > names after "source" ?
> >> >
> >> > cheers -ben
> >> >
> >> > [... snip ...]
> >>
> >>
> >>
> >>
> >>
> >> -
> >> cheers,
> >> Sanjay
> >> --
> >> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
> >>
> >>
>
>
>
>
>
> -
> cheers,
> Sanjay
> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
>
>

Re: [Pharo-users] Voyage

[Sanjay Minni]

I can download the file and shorten the name but the issue is it seems that
the process stops and remaining files and not downloaded, how to get around
that ?

to elaborate - only the first 7 files of this folder is copied/downloaded
into pharo-local/...
 
https://github.com/pharo-contributions/Cryptography/tree/master/source/Cryptography-MSCerts.package/Win32FFICertificateStore.class/instance



Ben Coman wrote
> On Fri, 7 Dec 2018 at 00:26, Sanjay Minni 

> sm@

>  wrote:
> 
>> Hi Ben,
>>
>> how to go about the hack ?
>>
>> it seems the file being looked for is this(from the github Cryptography
>> repository)
>> http://forum.world.st/file/t368721/CryptographyLoadErr.jpg;
>>
> but this is not copied in ...\pharo-local\...\sources\...
>> http://forum.world.st/file/t368721/CryptographyFilesInSource.jpg;
>>
>>
> Try manually downloading that file and put it in place named something
> short like e.g. "xx.st"
>  I'm not certain that will work, but worth a try.
> 
> Alternatively, install pharo in a short root folder "C:\x" to give it
> filenames plenty of headroom.
> Note, this might not be your problem, but should help scope it out.
> 
> 
> 
>> also
>> Voyage loading thru playground ultimately terminates as per screen below
>> (is
>> this an expected behaviour) ?
>> http://forum.world.st/file/t368721/VoyageLoadTermination.jpg;
>>
>>
>  I'm  not familiar with that.
> 
> cheers -ben
> 
> 
>>
>>
>> Ben Coman wrote
>> > On Wed, 5 Dec 2018 at 00:25, Sanjay Minni 
>>
>> > sm@
>>
>> >  wrote:
>> >
>> >> Hi Esteban,
>> >>
>> >> I get a Debug Popup as per below - how do I debug from here
>> >>
>> >> http://forum.world.st/file/t368721/VoyageIcebergLoadErr01.jpg;
>> >>
>> >> http://forum.world.st/file/t368721/VoyageLoadError01.jpg;
>> >>
>> >
>> > Is this on Windows?
>> > It could be that long path names continue to bite.
>> > Could you try a hack... go in on the command line and shorten the
>> > directory
>> > names after "source" ?
>> >
>> > cheers -ben
>> >
>> > [... snip ...]
>>
>>
>>
>>
>>
>> -
>> cheers,
>> Sanjay
>> --
>> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
>>
>>





-
cheers, 
Sanjay
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Re: [Pharo-users] Voyage

[Ben Coman]

On Fri, 7 Dec 2018 at 00:26, Sanjay Minni  wrote:

> Hi Ben,
>
> how to go about the hack ?
>
> it seems the file being looked for is this(from the github Cryptography
> repository)
> 
>
but this is not copied in ...\pharo-local\...\sources\...
> 
>
>
Try manually downloading that file and put it in place named something
short like e.g. "xx.st"
 I'm not certain that will work, but worth a try.

Alternatively, install pharo in a short root folder "C:\x" to give it
filenames plenty of headroom.
Note, this might not be your problem, but should help scope it out.



> also
> Voyage loading thru playground ultimately terminates as per screen below
> (is
> this an expected behaviour) ?
> 
>
>
 I'm  not familiar with that.

cheers -ben


>
>
> Ben Coman wrote
> > On Wed, 5 Dec 2018 at 00:25, Sanjay Minni 
>
> > sm@
>
> >  wrote:
> >
> >> Hi Esteban,
> >>
> >> I get a Debug Popup as per below - how do I debug from here
> >>
> >> http://forum.world.st/file/t368721/VoyageIcebergLoadErr01.jpg;
> >>
> >> http://forum.world.st/file/t368721/VoyageLoadError01.jpg;
> >>
> >
> > Is this on Windows?
> > It could be that long path names continue to bite.
> > Could you try a hack... go in on the command line and shorten the
> > directory
> > names after "source" ?
> >
> > cheers -ben
> >
> > [... snip ...]
>
>
>
>
>
> -
> cheers,
> Sanjay
> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
>
>

Re: [Pharo-users] Voyage

[Sanjay Minni]

Hi Ben,

how to go about the hack ?

it seems the file being looked for is this(from the github Cryptography
repository)
 

but this is not copied in ...\pharo-local\...\sources\...
 

also
Voyage loading thru playground ultimately terminates as per screen below (is
this an expected behaviour) ?
  



Ben Coman wrote
> On Wed, 5 Dec 2018 at 00:25, Sanjay Minni 

> sm@

>  wrote:
> 
>> Hi Esteban,
>>
>> I get a Debug Popup as per below - how do I debug from here
>>
>> http://forum.world.st/file/t368721/VoyageIcebergLoadErr01.jpg;
>>
>> http://forum.world.st/file/t368721/VoyageLoadError01.jpg;
>>
> 
> Is this on Windows?
> It could be that long path names continue to bite.
> Could you try a hack... go in on the command line and shorten the
> directory
> names after "source" ?
> 
> cheers -ben
> 
> [... snip ...]





-
cheers, 
Sanjay
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Re: [Pharo-users] Voyage

[Cyril Ferlicot]

On Sun, Dec 2, 2018 at 4:46 PM Esteban Lorenzano  wrote:
>
> So we just need to change the dependency. Cool :)
>
>

In fact the dependency was already changed by Norbert! The problem is
that we need a new release of mongotalk and to update the release used
by Voyage :)
So I cannot help here since I'm not part of pharo-nosql.


-- 
Cyril Ferlicot
https://ferlicot.fr

Re: [Pharo-users] Voyage

[Ben Coman]

On Wed, 5 Dec 2018 at 00:25, Sanjay Minni  wrote:

> Hi Esteban,
>
> I get a Debug Popup as per below - how do I debug from here
>
> 
>
> 
>

Is this on Windows?
It could be that long path names continue to bite.
Could you try a hack... go in on the command line and shorten the directory
names after "source" ?

cheers -ben

EstebanLM wrote
> > There is indeed a problem because cryptography package is still using an
> > old API: #ifNotNilDo: that does not exists anymore in Pharo.
> > You are probably seen something like this:
> >
> >
> >
> >
> > (And this is a bug)
> > Anyway, while we fix this, you can replace #ifNotNilDo: for #ifNotNil:,
> > then save and select “proceed”.
> >
> > That will allow voyage to load properly.
> >
> > Cheers,
> > Esteban
> >
> >
> >
> >> On 2 Dec 2018, at 12:39, Sanjay Minni 
>
> > sm@
>
> >  wrote:
> >>
> >> I am unable to load Voyage-Mongo and Voyage-Memory in  Pharo 7.0.0rC1
> >>
> >> tried using the scipt below and also thru the Catalog Browser entries
> for
> >> Voyage
> >> any pointers
> >>
> >>
> >> CyrilFerlicot wrote
> >>> Le 16/11/2018 à 02:02, horrido a écrit :
>  I'm trying to load Voyage for MongoDB and I'm having great difficulty.
>  The
>  docs seem to be out of date.
> 
>  What are the current instructions for doing this?
> 
>  The docs also refer to "Configurations Browser" in World Menu/Tools,
>  but
>  there is no longer any such thing.
> 
> 
> >>>
> >>> Hi,
> >>>
> >>> Voyage-Mongo
> >>>
> >>> Metacello new
> >>>repository: 'github://pharo-nosql/voyage/mc';
> >>>baseline: 'Voyage';
> >>>onConflictUseIncoming;
> >>>load: 'mongo tests'.
> >>>
> >>> Voyage-UnQLite
> >>>
> >>> Metacello new
> >>>repository: 'github://pharo-nosql/voyage/mc';
> >>>baseline: 'Voyage';
> >>>onConflictUseIncoming;
> >>>load: 'unqlite tests'.
> >>>
> >>> Voyage-Memory
> >>>
> >>> Metacello new
> >>>repository: 'github://pharo-nosql/voyage/mc';
> >>>baseline: 'Voyage';
> >>>onConflictUseIncoming;
> >>>load: 'memory tests'.
> >>>
> >>> Should work.
> >>>
> 
>  --
>  Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
> 
> >>>
> >>>
> >>> --
> >>> Cyril Ferlicot
> >>> https://ferlicot.fr
> >>>
> >>>
> >>>
> >>> signature.asc (836 bytes)
> >>> http://forum.world.st/attachment/5088985/0/signature.asc;
> >>
> >>
> >>
> >>
> >>
> >> -
> >> cheers,
> >> Sanjay
> >> --
> >> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
> >>
> >
> >
> >
> > Screenshot 2018-12-02 at 15.02.19.png (165K)
> > 
> http://forum.world.st/attachment/5090021/0/Screenshot%202018-12-02%20at%2015.02.19.png
> ;
>
>
>
>
>
> -
> cheers,
> Sanjay
> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
>
>

Re: [Pharo-users] Voyage

[Sanjay Minni]

Hi Esteban,

I get a Debug Popup as per below - how do I debug from here

 

 


EstebanLM wrote
> There is indeed a problem because cryptography package is still using an
> old API: #ifNotNilDo: that does not exists anymore in Pharo. 
> You are probably seen something like this: 
> 
> 
> 
> 
> (And this is a bug)
> Anyway, while we fix this, you can replace #ifNotNilDo: for #ifNotNil:,
> then save and select “proceed”.
> 
> That will allow voyage to load properly.
> 
> Cheers, 
> Esteban
> 
> 
> 
>> On 2 Dec 2018, at 12:39, Sanjay Minni 

> sm@

>  wrote:
>> 
>> I am unable to load Voyage-Mongo and Voyage-Memory in  Pharo 7.0.0rC1
>> 
>> tried using the scipt below and also thru the Catalog Browser entries for
>> Voyage
>> any pointers
>> 
>> 
>> CyrilFerlicot wrote
>>> Le 16/11/2018 à 02:02, horrido a écrit :
 I'm trying to load Voyage for MongoDB and I'm having great difficulty.
 The
 docs seem to be out of date.
 
 What are the current instructions for doing this?
 
 The docs also refer to "Configurations Browser" in World Menu/Tools,
 but
 there is no longer any such thing.
 
 
>>> 
>>> Hi,
>>> 
>>> Voyage-Mongo
>>> 
>>> Metacello new
>>>repository: 'github://pharo-nosql/voyage/mc';
>>>baseline: 'Voyage';
>>>onConflictUseIncoming;
>>>load: 'mongo tests'.
>>> 
>>> Voyage-UnQLite
>>> 
>>> Metacello new
>>>repository: 'github://pharo-nosql/voyage/mc';
>>>baseline: 'Voyage';
>>>onConflictUseIncoming;
>>>load: 'unqlite tests'.
>>> 
>>> Voyage-Memory
>>> 
>>> Metacello new
>>>repository: 'github://pharo-nosql/voyage/mc';
>>>baseline: 'Voyage';
>>>onConflictUseIncoming;
>>>load: 'memory tests'.
>>> 
>>> Should work.
>>> 
 
 --
 Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
 
>>> 
>>> 
>>> -- 
>>> Cyril Ferlicot
>>> https://ferlicot.fr
>>> 
>>> 
>>> 
>>> signature.asc (836 bytes)
>>> http://forum.world.st/attachment/5088985/0/signature.asc;
>> 
>> 
>> 
>> 
>> 
>> -
>> cheers, 
>> Sanjay
>> --
>> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
>> 
> 
> 
> 
> Screenshot 2018-12-02 at 15.02.19.png (165K)
> http://forum.world.st/attachment/5090021/0/Screenshot%202018-12-02%20at%2015.02.19.png;





-
cheers, 
Sanjay
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Re: [Pharo-users] Voyage

[Cyril Ferlicot]

On Sun 2 Dec 2018 at 18:49, Norbert Hartl via Pharo-users <
pharo-users@lists.pharo.org> wrote:

> I thought I did it already. Cannot check now, I don‘t have a computer
> right now.
>

IIRC it is not directly in voyage but in MongoTalk


> Am 02.12.2018 um 16:44 schrieb Esteban Lorenzano :
>
> So we just need to change the dependency. Cool :)
>
>
> On 2 Dec 2018, at 16:18, Norbert Hartl  wrote:
>
> I added PBKDF2 to the cryptography repository on github a while ago. One
> reason why I migrated cryptography in the first place
>
> Norbert
>
> Am 02.12.2018 um 15:59 schrieb Cyril Ferlicot :
>
>
>
> On Sun 2 Dec 2018 at 15:38, Esteban Lorenzano  wrote:
>
>> There was a cryptography version on GitHub, isn’t?
>>
>>
> Yes, but we need someone with the rights to write on PBKDF2 on StHub, or
> migrate it in github aswell to fix the issue.
>
>
>> On 2 Dec 2018, at 15:31, Cyril Ferlicot  wrote:
>>
>>
>>
>> On Sun 2 Dec 2018 at 15:08, Esteban Lorenzano 
>> wrote:
>>
>>> There is indeed a problem because cryptography package is still using an
>>> old API: #ifNotNilDo: that does not exists anymore in Pharo.
>>> You are probably seen something like this:
>>>
>>> 
>>>
>>
>>
>> I looked at it last time and the problem is that one of the dependency
>> hosted on StHub still depends on the StHub version of Cryptography.
>>
>> http://smalltalkhub.com/#!/~UdoSchneider/PBKDF2/
>>
>> But not many people can write on this project I think.
>>
>>
>>>
>>> (And this is a bug)
>>> Anyway, while we fix this, you can replace #ifNotNilDo: for #ifNotNil:,
>>> then save and select “proceed”.
>>>
>>> That will allow voyage to load properly.
>>>
>>> Cheers,
>>> Esteban
>>>
>>> --
>> Cyril Ferlicot
>> https://ferlicot.fr
>>
>>
>> --
> Cyril Ferlicot
> https://ferlicot.fr
>
>
> --
Cyril Ferlicot
https://ferlicot.fr

Re: [Pharo-users] Voyage

[Norbert Hartl via Pharo-users]

--- Begin Message ---
I thought I did it already. Cannot check now, I don‘t have a computer right now.

> Am 02.12.2018 um 16:44 schrieb Esteban Lorenzano :
> 
> So we just need to change the dependency. Cool :)
> 
> 
>> On 2 Dec 2018, at 16:18, Norbert Hartl  wrote:
>> 
>> I added PBKDF2 to the cryptography repository on github a while ago. One 
>> reason why I migrated cryptography in the first place
>> 
>> Norbert
>> 
>>> Am 02.12.2018 um 15:59 schrieb Cyril Ferlicot :
>>> 
>>> 
>>> 
 On Sun 2 Dec 2018 at 15:38, Esteban Lorenzano  wrote:
 There was a cryptography version on GitHub, isn’t?
 
>>> 
>>> Yes, but we need someone with the rights to write on PBKDF2 on StHub, or 
>>> migrate it in github aswell to fix the issue. 
>>> 
 
> On 2 Dec 2018, at 15:31, Cyril Ferlicot  wrote:
> 
> 
> 
> On Sun 2 Dec 2018 at 15:08, Esteban Lorenzano  wrote:
>> There is indeed a problem because cryptography package is still using an 
>> old API: #ifNotNilDo: that does not exists anymore in Pharo. 
>> You are probably seen something like this: 
>> 
>> 
 
> 
> 
> I looked at it last time and the problem is that one of the dependency 
> hosted on StHub still depends on the StHub version of Cryptography.
> 
> http://smalltalkhub.com/#!/~UdoSchneider/PBKDF2/
> 
> But not many people can write on this project I think. 
> 
>> 
>> 
>> (And this is a bug)
>> Anyway, while we fix this, you can replace #ifNotNilDo: for #ifNotNil:, 
>> then save and select “proceed”.
>> 
>> That will allow voyage to load properly.
>> 
>> Cheers, 
>> Esteban
>> 
> -- 
> Cyril Ferlicot
> https://ferlicot.fr
 
>>> -- 
>>> Cyril Ferlicot
>>> https://ferlicot.fr
> 
--- End Message ---

Re: [Pharo-users] Voyage

[Esteban Lorenzano]

So we just need to change the dependency. Cool :)


> On 2 Dec 2018, at 16:18, Norbert Hartl  wrote:
> 
> I added PBKDF2 to the cryptography repository on github a while ago. One 
> reason why I migrated cryptography in the first place
> 
> Norbert
> 
> Am 02.12.2018 um 15:59 schrieb Cyril Ferlicot  >:
> 
>> 
>> 
>> On Sun 2 Dec 2018 at 15:38, Esteban Lorenzano > > wrote:
>> There was a cryptography version on GitHub, isn’t?
>> 
>> 
>> Yes, but we need someone with the rights to write on PBKDF2 on StHub, or 
>> migrate it in github aswell to fix the issue. 
>> 
>> 
>>> On 2 Dec 2018, at 15:31, Cyril Ferlicot >> > wrote:
>>> 
>>> 
>>> 
>>> On Sun 2 Dec 2018 at 15:08, Esteban Lorenzano >> > wrote:
>>> There is indeed a problem because cryptography package is still using an 
>>> old API: #ifNotNilDo: that does not exists anymore in Pharo. 
>>> You are probably seen something like this: 
>>> 
>>> 
>> 
>>> 
>>> 
>>> I looked at it last time and the problem is that one of the dependency 
>>> hosted on StHub still depends on the StHub version of Cryptography.
>>> 
>>> http://smalltalkhub.com/#!/~UdoSchneider/PBKDF2/ 
>>> 
>>> But not many people can write on this project I think. 
>>> 
>>> 
>>> 
>>> (And this is a bug)
>>> Anyway, while we fix this, you can replace #ifNotNilDo: for #ifNotNil:, 
>>> then save and select “proceed”.
>>> 
>>> That will allow voyage to load properly.
>>> 
>>> Cheers, 
>>> Esteban
>>> 
>>> -- 
>>> Cyril Ferlicot
>>> https://ferlicot.fr 
>> -- 
>> Cyril Ferlicot
>> https://ferlicot.fr 

Re: [Pharo-users] Voyage

[Norbert Hartl]

I added PBKDF2 to the cryptography repository on github a while ago. One reason 
why I migrated cryptography in the first place

Norbert

> Am 02.12.2018 um 15:59 schrieb Cyril Ferlicot :
> 
> 
> 
>> On Sun 2 Dec 2018 at 15:38, Esteban Lorenzano  wrote:
>> There was a cryptography version on GitHub, isn’t?
>> 
> 
> Yes, but we need someone with the rights to write on PBKDF2 on StHub, or 
> migrate it in github aswell to fix the issue. 
> 
>> 
>>> On 2 Dec 2018, at 15:31, Cyril Ferlicot  wrote:
>>> 
>>> 
>>> 
>>> On Sun 2 Dec 2018 at 15:08, Esteban Lorenzano  wrote:
 There is indeed a problem because cryptography package is still using an 
 old API: #ifNotNilDo: that does not exists anymore in Pharo. 
 You are probably seen something like this: 
 
 
>> 
>>> 
>>> 
>>> I looked at it last time and the problem is that one of the dependency 
>>> hosted on StHub still depends on the StHub version of Cryptography.
>>> 
>>> http://smalltalkhub.com/#!/~UdoSchneider/PBKDF2/
>>> 
>>> But not many people can write on this project I think. 
>>> 
 
 
 (And this is a bug)
 Anyway, while we fix this, you can replace #ifNotNilDo: for #ifNotNil:, 
 then save and select “proceed”.
 
 That will allow voyage to load properly.
 
 Cheers, 
 Esteban
 
>>> -- 
>>> Cyril Ferlicot
>>> https://ferlicot.fr
>> 
> -- 
> Cyril Ferlicot
> https://ferlicot.fr

Re: [Pharo-users] Voyage

[Cyril Ferlicot]

On Sun 2 Dec 2018 at 15:38, Esteban Lorenzano  wrote:

> There was a cryptography version on GitHub, isn’t?
>
>
Yes, but we need someone with the rights to write on PBKDF2 on StHub, or
migrate it in github aswell to fix the issue.


> On 2 Dec 2018, at 15:31, Cyril Ferlicot  wrote:
>
>
>
> On Sun 2 Dec 2018 at 15:08, Esteban Lorenzano  wrote:
>
>> There is indeed a problem because cryptography package is still using an
>> old API: #ifNotNilDo: that does not exists anymore in Pharo.
>> You are probably seen something like this:
>>
>> 
>>
>
>
> I looked at it last time and the problem is that one of the dependency
> hosted on StHub still depends on the StHub version of Cryptography.
>
> http://smalltalkhub.com/#!/~UdoSchneider/PBKDF2/
>
> But not many people can write on this project I think.
>
>
>>
>> (And this is a bug)
>> Anyway, while we fix this, you can replace #ifNotNilDo: for #ifNotNil:,
>> then save and select “proceed”.
>>
>> That will allow voyage to load properly.
>>
>> Cheers,
>> Esteban
>>
>> --
> Cyril Ferlicot
> https://ferlicot.fr
>
>
> --
Cyril Ferlicot
https://ferlicot.fr

Re: [Pharo-users] Voyage

[Esteban Lorenzano]

There was a cryptography version on GitHub, isn’t?


> On 2 Dec 2018, at 15:31, Cyril Ferlicot  wrote:
> 
> 
> 
> On Sun 2 Dec 2018 at 15:08, Esteban Lorenzano  > wrote:
> There is indeed a problem because cryptography package is still using an old 
> API: #ifNotNilDo: that does not exists anymore in Pharo. 
> You are probably seen something like this: 
> 
> 
> 
> 
> I looked at it last time and the problem is that one of the dependency hosted 
> on StHub still depends on the StHub version of Cryptography.
> 
> http://smalltalkhub.com/#!/~UdoSchneider/PBKDF2/ 
> 
> But not many people can write on this project I think. 
> 
> 
> 
> (And this is a bug)
> Anyway, while we fix this, you can replace #ifNotNilDo: for #ifNotNil:, then 
> save and select “proceed”.
> 
> That will allow voyage to load properly.
> 
> Cheers, 
> Esteban
> 
> -- 
> Cyril Ferlicot
> https://ferlicot.fr 

Re: [Pharo-users] Voyage

[Sanjay Minni]

I am unable to load Voyage-Mongo and Voyage-Memory in  Pharo 7.0.0rC1

tried using the scipt below and also thru the Catalog Browser entries for
Voyage
any pointers


CyrilFerlicot wrote
> Le 16/11/2018 à 02:02, horrido a écrit :
>> I'm trying to load Voyage for MongoDB and I'm having great difficulty.
>> The
>> docs seem to be out of date.
>> 
>> What are the current instructions for doing this?
>> 
>> The docs also refer to "Configurations Browser" in World Menu/Tools, but
>> there is no longer any such thing.
>> 
>> 
> 
> Hi,
> 
> Voyage-Mongo
> 
> Metacello new
> repository: 'github://pharo-nosql/voyage/mc';
> baseline: 'Voyage';
> onConflictUseIncoming;
> load: 'mongo tests'.
> 
> Voyage-UnQLite
> 
> Metacello new
> repository: 'github://pharo-nosql/voyage/mc';
> baseline: 'Voyage';
> onConflictUseIncoming;
> load: 'unqlite tests'.
> 
> Voyage-Memory
> 
> Metacello new
> repository: 'github://pharo-nosql/voyage/mc';
> baseline: 'Voyage';
> onConflictUseIncoming;
> load: 'memory tests'.
> 
> Should work.
> 
>> 
>> --
>> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
>> 
> 
> 
> -- 
> Cyril Ferlicot
> https://ferlicot.fr
> 
> 
> 
> signature.asc (836 bytes)
> http://forum.world.st/attachment/5088985/0/signature.asc;





-
cheers, 
Sanjay
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Re: [Pharo-users] Voyage

[Tim Mackinnon]

Wasn’t someone looking at enhancements to pillar and it’s publishing 
environment (I forget it’s name) - this is a great usecase, generating menu 
names for docs (and other similar constants) so that name changes can be 
accommodated automatically... a thought anyway.

Tim

Sent from my iPhone

> On 16 Nov 2018, at 17:47, Sven Van Caekenberghe  wrote:
> 
> 
> 
>> On 16 Nov 2018, at 02:02, horrido  wrote:
>> 
>> The docs also refer to "Configurations Browser" in World Menu/Tools, but
> 
> It is called Catalog (name change happened long ago).
> 
> World Menu > Tools > Catalog Browser = "Pharo Project Catalog"
> 

Re: [Pharo-users] Voyage

[Sven Van Caekenberghe]

> On 16 Nov 2018, at 02:02, horrido  wrote:
> 
> The docs also refer to "Configurations Browser" in World Menu/Tools, but

It is called Catalog (name change happened long ago).

World Menu > Tools > Catalog Browser = "Pharo Project Catalog"

Re: [Pharo-users] Voyage

[Cyril Ferlicot D.]

Le 16/11/2018 à 02:02, horrido a écrit :
> I'm trying to load Voyage for MongoDB and I'm having great difficulty. The
> docs seem to be out of date.
> 
> What are the current instructions for doing this?
> 
> The docs also refer to "Configurations Browser" in World Menu/Tools, but
> there is no longer any such thing.
> 
> 

Hi,

Voyage-Mongo

Metacello new
repository: 'github://pharo-nosql/voyage/mc';
baseline: 'Voyage';
onConflictUseIncoming;
load: 'mongo tests'.

Voyage-UnQLite

Metacello new
repository: 'github://pharo-nosql/voyage/mc';
baseline: 'Voyage';
onConflictUseIncoming;
load: 'unqlite tests'.

Voyage-Memory

Metacello new
repository: 'github://pharo-nosql/voyage/mc';
baseline: 'Voyage';
onConflictUseIncoming;
load: 'memory tests'.

Should work.

> 
> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
> 


-- 
Cyril Ferlicot
https://ferlicot.fr



signature.asc
Description: OpenPGP digital signature

Re: [Pharo-users] Voyage-UnQLite hangs on Windows

[Esteban Lorenzano]

Hi,

> On 20 Jun 2018, at 17:24, Marco Hörning  wrote:
> 
> I started evaluating Voyage-UnQLite, current Pharo 6.1, Windows 10
> 
> installed:
> 
> Metacello  newrepository:  'github://pharo-nosql/voyage/mc';
>   baseline:  'Voyage';
>   load:  'unqlite tests'.
> 
> Using latest dll (Aug 10, 2016)
> https://github.com/pharo-nosql/PunQLite/commits/master/binary/win/unqlite.dll
> 
> Basic test trying to store and reload a simple object containing a string 
> instance variable
> 
> Object subclass: #SomeTag
> 
>instanceVariableNames: 'designation'
> 
> SomeTag class>>isVoyageRoot
> 
>^ true
> 
> Here's the Testcase code:
> 
> VoyageTest>>setUp
> 
>repository := VOUnQLiteRepository on: FileSystem workingDirectory / 
> 'TestDatabase.db'.
> 
>repository open
> 
> VoyageTest>>tearDown
> 
>repository close
> 
> 
> Running tests now:
> 
> VoyageTest>>testVoyageUnQLiteStartup
> 
>   self assert: repository isOpen
> 
> 
> that works, db an be opened and closed. Now trying to store an object
> 
> VoyageTest>>testVoyageUnQLiteWrite
> 
>|  aTag  |
> 
>   self assert: SomeTag isVoyageRoot.
> 
>   aTag := SomeTag new designation:'aTag'.
> 
>   repository save: aTag
> 
> 
> 
> works, if I open a Database (PunQLite) Browser it shows me the entries 
> 'SomeTag' and 'SomeTag_0'. Trying to load the object
> 
> VoyageTest>>testVoyageUnQLiteRead
> 
>   | fetchedTags |
> 
>   fetchedTags := repository selectAll:SomeTag
> 
> 
> that does not work. System hangs and I get a Testcase timeout  with a 
> "TestTookTooMuchTime" exception.
> 
> the external call in
> 
> UnQLilteFFI>>array: pArray walk: xWalk data: pUserData
> 
> 
> does not come back.
> 
> 
> Any comments or bright ideas what's wrong ? Anybody experience with 
> Voyage-UnQLite on Windows ?

well… thing is I never tried it on windows so I don’t know what may be wrong :(
also, there is a chance is something more general from voyage-unqlite… 

give me a couple of days and I will check it.

cheers,
Esteban 


> 
> Kind Regards from Germany
> Marco
> 
> 
> 
> 
> 
> 
> 

Re: [Pharo-users] [Voyage] How to declare an instance variable as transient?

[sergio ruiz]

ah! thanks!


On May 3, 2018 at 5:06:18 PM, Alejandro Infante (alejandroinfant...@gmail.com) 
wrote:

Hi Sergio,

You have to add a method to the class side with a pragma. In my case, I wanted 
to set the instance variable “questionReferences” to transient.

myClass class>>mongoQuestionReferences

^VOTransientDescription new
attributeName: 'questionReferences';
yourself

Cheers!
Alejandro

On Apr 30, 2018, at 3:21 PM, sergio ruiz  wrote:

Hi, all..

I have an instance variable that I don’t want to save as part of the full 
project. I was wondering how to set this up.

The documentation says:
Lastly, attributes can be excluded from storage (and hence retrieval) by re- 
turning a VOMongoTransientDescription instance as the attribute descrip- tor.

But I am not sure how to set this up in my class.

thanks! 



peace,
sergio
photographer, journalist, visionary

Public Key: http://bit.ly/29z9fG0
#BitMessage BM-NBaswViL21xqgg9STRJjaJaUoyiNe2dV
http://www.codeandmusic.com
http://www.twitter.com/sergio_101
http://www.facebook.com/sergio101


peace,
sergio
photographer, journalist, visionary

Public Key: http://bit.ly/29z9fG0
#BitMessage BM-NBaswViL21xqgg9STRJjaJaUoyiNe2dV
http://www.codeandmusic.com
http://www.twitter.com/sergio_101
http://www.facebook.com/sergio101

signature.asc
Description: Message signed with OpenPGP using AMPGpg

Re: [Pharo-users] [Voyage] How to declare an instance variable as transient?

[Alejandro Infante]

Hi Sergio,

You have to add a method to the class side with a pragma. In my case, I wanted 
to set the instance variable “questionReferences” to transient.

myClass class>>mongoQuestionReferences


^VOTransientDescription new
attributeName: 'questionReferences';
yourself

Cheers!
Alejandro

> On Apr 30, 2018, at 3:21 PM, sergio ruiz  wrote:
> 
> Hi, all..
> 
> I have an instance variable that I don’t want to save as part of the full 
> project. I was wondering how to set this up.
> 
> The documentation says:
> Lastly, attributes can be excluded from storage (and hence retrieval) by re- 
> turning a VOMongoTransientDescription instance as the attribute descrip- tor.
> 
> But I am not sure how to set this up in my class.
> 
> thanks! 
> 
> 
> 
> peace,
> sergio
> photographer, journalist, visionary
> 
> Public Key: http://bit.ly/29z9fG0 
> #BitMessage BM-NBaswViL21xqgg9STRJjaJaUoyiNe2dV
> http://www.codeandmusic.com 
> http://www.twitter.com/sergio_101 
> http://www.facebook.com/sergio101 

Re: [Pharo-users] [Voyage] Possible to save an OrderedCollection?

[sergio ruiz]

Ah.. ok. this did it..

So, this works, meaning that the production code i have in place is the 
problem..

I must have a loop somewhere..

I can’t find it for the life of me..



On April 27, 2018 at 4:10:53 PM, Esteban Lorenzano (esteba...@gmail.com) wrote:

did you add the property after doing some tests? 
in that case, you need to reset Voyage caché.

peace,
sergio
photographer, journalist, visionary

Public Key: http://bit.ly/29z9fG0
#BitMessage BM-NBaswViL21xqgg9STRJjaJaUoyiNe2dV
http://www.codeandmusic.com
http://www.twitter.com/sergio_101
http://www.facebook.com/sergio101

signature.asc
Description: Message signed with OpenPGP using AMPGpg

Re: [Pharo-users] [Voyage] Possible to save an OrderedCollection?

[Esteban Lorenzano]

> On 27 Apr 2018, at 15:30, sergio ruiz  wrote:
> 
> Hi, esteban..
> 
> In this case, the persisted object is TestBox..
> 
> it does show up just fine in Mongo, but the OrderedCollection of points does 
> not.

did you add the property after doing some tests? 
in that case, you need to reset Voyage caché.

usually, 

VORepository current flush

will do it

Esteban
> 
> On April 27, 2018 at 8:57:26 AM, Esteban Lorenzano (esteba...@gmail.com 
> ) wrote:
> 
>> 
>> what you need to save is the persistent object, the one marked as 
>> “isVoyageRoot” in class side.
> 
> peace,
> sergio
> photographer, journalist, visionary
> 
> Public Key: http://bit.ly/29z9fG0 
> #BitMessage BM-NBaswViL21xqgg9STRJjaJaUoyiNe2dV
> http://www.codeandmusic.com 
> http://www.twitter.com/sergio_101 
> http://www.facebook.com/sergio101 

Re: [Pharo-users] [Voyage] Possible to save an OrderedCollection?

[sergio ruiz]

Hi, esteban..

In this case, the persisted object is TestBox..

it does show up just fine in Mongo, but the OrderedCollection of points does 
not.

On April 27, 2018 at 8:57:26 AM, Esteban Lorenzano (esteba...@gmail.com) wrote:


what you need to save is the persistent object, the one marked as 
“isVoyageRoot” in class side.

peace,
sergio
photographer, journalist, visionary

Public Key: http://bit.ly/29z9fG0
#BitMessage BM-NBaswViL21xqgg9STRJjaJaUoyiNe2dV
http://www.codeandmusic.com
http://www.twitter.com/sergio_101
http://www.facebook.com/sergio101

signature.asc
Description: Message signed with OpenPGP using AMPGpg

Re: [Pharo-users] [Voyage] Possible to save an OrderedCollection?

[Esteban Lorenzano]

hi,

what you need to save is the persistent object, the one marked as 
“isVoyageRoot” in class side.

cheers,
Esteban

> On 27 Apr 2018, at 14:44, sergio ruiz  wrote:
> 
> 
> For some reason, I am not able to do this:
> 
> Object subclass: #TestBox
>   instanceVariableNames: 'origin corner pointList'
>   classVariableNames: ''
>   poolDictionaries: ''
>   category: 'PrintBot-Models’!
> 
> initialize
>   pointList := OrderedCollection new.
> 
> 
> If i do something like below, I don’t see the list of points ever show up in 
> mongo..
> 
> Ideas?
> 
> b := TestBox new.
> b save.
> p1 := Point x:0 y:0.
> p1 save.
> p2 := Point x:12 y:343.
> p2 save.
> 
> b origin: p1.
> b corner: p2.
> 
> b save.
> 
> b pointList add: p1.
> b save.
> b pointList add: p2.
> b save.
> 
> 
> 
> 
> peace,
> sergio
> photographer, journalist, visionary
> 
> Public Key: http://bit.ly/29z9fG0 
> #BitMessage BM-NBaswViL21xqgg9STRJjaJaUoyiNe2dV
> http://www.codeandmusic.com 
> http://www.twitter.com/sergio_101 
> http://www.facebook.com/sergio101 

Re: [Pharo-users] Voyage and Instance Mode

[Stephane Ducasse]

Can you do a pull request to update the book?
Or do we let rot the documentation?

Is the same sentence present in the Voyage booklet?
Stef

On Thu, Jan 25, 2018 at 11:27 PM, Esteban Lorenzano  wrote:
>
>
> On 25 Jan 2018, at 23:24, Dominique Dartois  wrote:
>
> Thanks Esteban.
> I was fooled by the doc : "In instance mode, the first argument is always
> the repository on which to performed the operation"...
> Well, not really, but the object to store.
>
>
> yeah, it should say: the receiver.
>
>
> Regards
>
> 2018-01-25 23:07 GMT+01:00 Esteban Lorenzano :
>>
>>
>>
>> > On 25 Jan 2018, at 23:03, Dominique Dartois  wrote:
>> >
>> > Hello all.
>> >
>> > I'am learning to use Voyage by trying the examples in the Voyage doc (in
>> > the Enterprise Pharo book).
>> > I read "By default, Voyage works in instance mode".
>> > If I run the example in instance mode, I get an error via the debugger.
>> >
>> > |repo anAssociation|
>> > repo := VOMemoryRepository new.
>> > anAssociation := #answer -> 42.
>> > anAssociation save: repo.
>>
>> repo save: anAssociation :)
>>
>> cheers!
>> Esteban
>>
>> >  ==> "Instance of Association did not understand #save:"
>> >
>> > What am I doing wrong?
>> >
>> > --
>> > Dominique
>>
>>
>
>
>
> --
> Dominique
>
>

Re: [Pharo-users] Voyage and Instance Mode

[Esteban Lorenzano]

> On 25 Jan 2018, at 23:24, Dominique Dartois  wrote:
> 
> Thanks Esteban.
> I was fooled by the doc : "In instance mode, the first argument is always the 
> repository on which to performed the operation"...
> Well, not really, but the object to store.

yeah, it should say: the receiver.

> 
> Regards
> 
> 2018-01-25 23:07 GMT+01:00 Esteban Lorenzano  >:
> 
> 
> > On 25 Jan 2018, at 23:03, Dominique Dartois  > > wrote:
> >
> > Hello all.
> >
> > I'am learning to use Voyage by trying the examples in the Voyage doc (in 
> > the Enterprise Pharo book).
> > I read "By default, Voyage works in instance mode".
> > If I run the example in instance mode, I get an error via the debugger.
> >
> > |repo anAssociation|
> > repo := VOMemoryRepository new.
> > anAssociation := #answer -> 42.
> > anAssociation save: repo.
> 
> repo save: anAssociation :)
> 
> cheers!
> Esteban
> 
> >  ==> "Instance of Association did not understand #save:"
> >
> > What am I doing wrong?
> >
> > --
> > Dominique
> 
> 
> 
> 
> 
> -- 
> Dominique

Re: [Pharo-users] Voyage and Instance Mode

[Dominique Dartois]

Thanks Esteban.
I was fooled by the doc : "In instance mode, the first argument is always
the repository on which to performed the operation"...
Well, not really, but the object to store.

Regards

2018-01-25 23:07 GMT+01:00 Esteban Lorenzano :

>
>
> > On 25 Jan 2018, at 23:03, Dominique Dartois  wrote:
> >
> > Hello all.
> >
> > I'am learning to use Voyage by trying the examples in the Voyage doc (in
> the Enterprise Pharo book).
> > I read "By default, Voyage works in instance mode".
> > If I run the example in instance mode, I get an error via the debugger.
> >
> > |repo anAssociation|
> > repo := VOMemoryRepository new.
> > anAssociation := #answer -> 42.
> > anAssociation save: repo.
>
> repo save: anAssociation :)
>
> cheers!
> Esteban
>
> >  ==> "Instance of Association did not understand #save:"
> >
> > What am I doing wrong?
> >
> > --
> > Dominique
>
>
>


-- 
Dominique

Re: [Pharo-users] Voyage and Instance Mode

[Esteban Lorenzano]

> On 25 Jan 2018, at 23:03, Dominique Dartois  wrote:
> 
> Hello all.
> 
> I'am learning to use Voyage by trying the examples in the Voyage doc (in the 
> Enterprise Pharo book).
> I read "By default, Voyage works in instance mode".
> If I run the example in instance mode, I get an error via the debugger.
> 
> |repo anAssociation|
> repo := VOMemoryRepository new.
> anAssociation := #answer -> 42.
> anAssociation save: repo.

repo save: anAssociation :)

cheers!
Esteban

>  ==> "Instance of Association did not understand #save:"
> 
> What am I doing wrong?
> 
> -- 
> Dominique

Re: [Pharo-users] Voyage - collecting data from Mongo

[Stephane Ducasse]

Tx I will add that to the Voyage booklet I will edit soon :)



On Tue, May 2, 2017 at 3:29 PM, Mark Rizun  wrote:

> Hi,
>
> the solution to my initial issue is to create a class MyClass with two
> class side methods
>
> MyClass class >> isVoyageRoot
> ^ true
>
> MyClass class >> descriptionContainer
> 
> ^ VOContainer new
> collectionName: 'myCollection';
> yourself
>
> Also, to properly read the data one should add instance variables to
> depending on what is in the database. For example:
>
> { "_id" : ObjectId("5900a0175bc65a2b7973b48a"), "item" : "canvas", "qty"
> : 100, "tags" : [ "cotton" ] }
>
> In this case MyClass should have instanceVariables: 'item qty tags' and
> accessors.
> Plus, on the class side
>
> mongoItem
> 
> ^ VOToOneDescription new
> attributeName: 'item';
> kind: String;
> yourself
>
> mongoQty
> 
> ^ VOToOneDescription new
> attributeName: 'qty';
> kind: Integer;
> yourself
>
> mongoTags
> 
> ^ VOToOneDescription new
> attributeName: 'tags';
> kind: OrderedCollection;
> yourself
>
> After that one can connect to database and get the information.
>
> | repository |
> repository := VOMongoRepository database: 'databaseName'.
> repository selectAll: MyClass
>
> Big thanks to Sabine, Esteban and Holger!
>
> Cheers,
> Mark
>
> 2017-04-30 19:20 GMT+02:00 Sabine Manaa :
>
>> Happy to help. I got this information from Udo Schneider in slack several
>> weeks ago.
>> As far as I know, he works on an update for several things concerning
>> mongo but I don't know when he will release it.
>>
>>
>> chrismihaylyk [via Smalltalk] <[hidden email]
>> > schrieb am So.
>> 30. Apr. 2017 um 16:45:
>>
>>> Sabine, thank you very much! It's very helpful, work fine.
>>> 2017-04-30 17:09 GMT+03:00 Sabine Manaa <[hidden email]
>>> >:
>>>
 Khrystyna ,

 I also use a new version of mongo with authentication (but only old
 version) and wired Tiger.

 I am not sure but possibly you can try to overwrite the following
 method to fix the problem:

 MongoDatabase>>collections
 | reply names |
 reply := self command: {(#listCollections -> 1)} asDictionary.
 names := ((reply at: 'cursor') at: 'firstBatch') collect: [ :each |
 each at: #name ].
 ^ names collect: [ :each | MongoCollection database: self name: each ]

>>> 2017-04-30 12:24 GMT+02:00 Mark Rizun [via Smalltalk] <[hidden email]
 >:

>>>
> Mark
>> once you have a solution could you post it because I would like to
>> add your question to the voyage chapter.
>> stef
>>
>
> Sure thing, Stef.
>
>
> --
> If you reply to this email, your message will be added to the
> discussion below:
> http://forum.world.st/Voyage-collecting-data-from-Mongo-tp49
> 44784p4944944.html
>
 To start a new topic under Pharo Smalltalk Users, email [hidden email]
> 
>
 To unsubscribe from Pharo Smalltalk Users, click here.
> NAML
> 
>
 --
 View this message in context: Re: Voyage - collecting data from Mongo
 

 Sent from the Pharo Smalltalk Users mailing list archive
  at
 Nabble.com.

>>> If you reply to this email, your message will be added to the discussion
>>> below:
>>> http://forum.world.st/Voyage-collecting-data-from-Mongo-tp49
>>> 44784p4944955.html
>>> To start a new topic under Pharo Smalltalk Users, email [hidden email]
>>> 
>>> To unsubscribe from Pharo Smalltalk Users, click here.
>>> NAML
>>> 
>>>
>>
>> --
>> View this message in context: Re: Voyage - collecting data from Mongo
>> 
>> Sent from the Pharo Smalltalk Users mailing list archive
>>  at
>> Nabble.com.
>>
>

Re: [Pharo-users] Voyage - collecting data from Mongo

[Mark Rizun]

Hi,

the solution to my initial issue is to create a class MyClass with two
class side methods

MyClass class >> isVoyageRoot
^ true

MyClass class >> descriptionContainer

^ VOContainer new
collectionName: 'myCollection';
yourself

Also, to properly read the data one should add instance variables to
depending on what is in the database. For example:

{ "_id" : ObjectId("5900a0175bc65a2b7973b48a"), "item" : "canvas", "qty" :
100, "tags" : [ "cotton" ] }

In this case MyClass should have instanceVariables: 'item qty tags' and
accessors.
Plus, on the class side

mongoItem

^ VOToOneDescription new
attributeName: 'item';
kind: String;
yourself

mongoQty

^ VOToOneDescription new
attributeName: 'qty';
kind: Integer;
yourself

mongoTags

^ VOToOneDescription new
attributeName: 'tags';
kind: OrderedCollection;
yourself

After that one can connect to database and get the information.

| repository |
repository := VOMongoRepository database: 'databaseName'.
repository selectAll: MyClass

Big thanks to Sabine, Esteban and Holger!

Cheers,
Mark

2017-04-30 19:20 GMT+02:00 Sabine Manaa :

> Happy to help. I got this information from Udo Schneider in slack several
> weeks ago.
> As far as I know, he works on an update for several things concerning
> mongo but I don't know when he will release it.
>
>
> chrismihaylyk [via Smalltalk] <[hidden email]
> > schrieb am So.
> 30. Apr. 2017 um 16:45:
>
>> Sabine, thank you very much! It's very helpful, work fine.
>> 2017-04-30 17:09 GMT+03:00 Sabine Manaa <[hidden email]
>> >:
>>
>>> Khrystyna ,
>>>
>>> I also use a new version of mongo with authentication (but only old
>>> version) and wired Tiger.
>>>
>>> I am not sure but possibly you can try to overwrite the following method
>>> to fix the problem:
>>>
>>> MongoDatabase>>collections
>>> | reply names |
>>> reply := self command: {(#listCollections -> 1)} asDictionary.
>>> names := ((reply at: 'cursor') at: 'firstBatch') collect: [ :each | each
>>> at: #name ].
>>> ^ names collect: [ :each | MongoCollection database: self name: each ]
>>>
>> 2017-04-30 12:24 GMT+02:00 Mark Rizun [via Smalltalk] <[hidden email]
>>> >:
>>>
>>
 Mark
> once you have a solution could you post it because I would like to add
> your question to the voyage chapter.
> stef
>

 Sure thing, Stef.


 --
 If you reply to this email, your message will be added to the
 discussion below:
 http://forum.world.st/Voyage-collecting-data-from-Mongo-
 tp4944784p4944944.html

>>> To start a new topic under Pharo Smalltalk Users, email [hidden email]
 

>>> To unsubscribe from Pharo Smalltalk Users, click here.
 NAML
 

>>> --
>>> View this message in context: Re: Voyage - collecting data from Mongo
>>> 
>>>
>>> Sent from the Pharo Smalltalk Users mailing list archive
>>>  at
>>> Nabble.com.
>>>
>> If you reply to this email, your message will be added to the discussion
>> below:
>> http://forum.world.st/Voyage-collecting-data-from-Mongo-
>> tp4944784p4944955.html
>> To start a new topic under Pharo Smalltalk Users, email [hidden email]
>> 
>> To unsubscribe from Pharo Smalltalk Users, click here.
>> NAML
>> 
>>
>
> --
> View this message in context: Re: Voyage - collecting data from Mongo
> 
> Sent from the Pharo Smalltalk Users mailing list archive
>  at Nabble.com.
>

Re: [Pharo-users] Voyage - collecting data from Mongo

[Sabine Manaa]

Happy to help. I got this information from Udo Schneider in slack several
weeks ago.
As far as I know, he works on an update for several things concerning mongo
but I don't know when he will release it.


chrismihaylyk [via Smalltalk]  schrieb
am So. 30. Apr. 2017 um 16:45:

> Sabine, thank you very much! It's very helpful, work fine.
> 2017-04-30 17:09 GMT+03:00 Sabine Manaa <[hidden email]
> >:
>
>> Khrystyna ,
>>
>> I also use a new version of mongo with authentication (but only old
>> version) and wired Tiger.
>>
>> I am not sure but possibly you can try to overwrite the following method
>> to fix the problem:
>>
>> MongoDatabase>>collections
>> | reply names |
>> reply := self command: {(#listCollections -> 1)} asDictionary.
>> names := ((reply at: 'cursor') at: 'firstBatch') collect: [ :each | each
>> at: #name ].
>> ^ names collect: [ :each | MongoCollection database: self name: each ]
>>
> 2017-04-30 12:24 GMT+02:00 Mark Rizun [via Smalltalk] <[hidden email]
>> >:
>>
>
>>> Mark
 once you have a solution could you post it because I would like to add
 your question to the voyage chapter.
 stef

>>>
>>> Sure thing, Stef.
>>>
>>>
>>> --
>>> If you reply to this email, your message will be added to the discussion
>>> below:
>>>
>>> http://forum.world.st/Voyage-collecting-data-from-Mongo-tp4944784p4944944.html
>>>
>> To start a new topic under Pharo Smalltalk Users, email [hidden email]
>>> 
>>>
>> To unsubscribe from Pharo Smalltalk Users, click here.
>>> NAML
>>> 
>>>
>> --
>> View this message in context: Re: Voyage - collecting data from Mongo
>> 
>>
>> Sent from the Pharo Smalltalk Users mailing list archive
>>  at
>> Nabble.com.
>>
> If you reply to this email, your message will be added to the discussion
> below:
>
> http://forum.world.st/Voyage-collecting-data-from-Mongo-tp4944784p4944955.html
> To start a new topic under Pharo Smalltalk Users, email
> ml+s1294792n1310670...@n4.nabble.com
> To unsubscribe from Pharo Smalltalk Users, click here
> 
> .
> NAML
> 
>




--
View this message in context: 
http://forum.world.st/Voyage-collecting-data-from-Mongo-tp4944784p4944977.html
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Re: [Pharo-users] Voyage - collecting data from Mongo

[Христина Михайлюк]

Sabine, thank you very much! It's very helpful, work fine.

2017-04-30 17:09 GMT+03:00 Sabine Manaa :

> Khrystyna ,
>
> I also use a new version of mongo with authentication (but only old
> version) and wired Tiger.
>
> I am not sure but possibly you can try to overwrite the following method
> to fix the problem:
>
> MongoDatabase>>collections
> | reply names |
> reply := self command: {(#listCollections -> 1)} asDictionary.
> names := ((reply at: 'cursor') at: 'firstBatch') collect: [ :each | each
> at: #name ].
> ^ names collect: [ :each | MongoCollection database: self name: each ]
>
> 2017-04-30 12:24 GMT+02:00 Mark Rizun [via Smalltalk] <[hidden email]
> >:
>
>>
>> Mark
>>> once you have a solution could you post it because I would like to add
>>> your question to the voyage chapter.
>>> stef
>>>
>>
>> Sure thing, Stef.
>>
>>
>> --
>> If you reply to this email, your message will be added to the discussion
>> below:
>> http://forum.world.st/Voyage-collecting-data-from-Mongo-tp49
>> 44784p4944944.html
>> To start a new topic under Pharo Smalltalk Users, email [hidden email]
>> 
>> To unsubscribe from Pharo Smalltalk Users, click here.
>> NAML
>> 
>>
>
>
> --
> View this message in context: Re: Voyage - collecting data from Mongo
> 
>
> Sent from the Pharo Smalltalk Users mailing list archive
>  at Nabble.com.
>

Re: [Pharo-users] Voyage - collecting data from Mongo

[Sabine Manaa]

Khrystyna ,

I also use a new version of mongo with authentication (but only old
version) and wired Tiger.

I am not sure but possibly you can try to overwrite the following method to
fix the problem:

MongoDatabase>>collections
| reply names |
reply := self command: {(#listCollections -> 1)} asDictionary.
names := ((reply at: 'cursor') at: 'firstBatch') collect: [ :each | each
at: #name ].
^ names collect: [ :each | MongoCollection database: self name: each ]

2017-04-30 12:24 GMT+02:00 Mark Rizun [via Smalltalk] <
ml+s1294792n4944944...@n4.nabble.com>:

>
> Mark
>> once you have a solution could you post it because I would like to add
>> your question to the voyage chapter.
>> stef
>>
>
> Sure thing, Stef.
>
>
> --
> If you reply to this email, your message will be added to the discussion
> below:
> http://forum.world.st/Voyage-collecting-data-from-Mongo-
> tp4944784p4944944.html
> To start a new topic under Pharo Smalltalk Users, email
> ml+s1294792n1310670...@n4.nabble.com
> To unsubscribe from Pharo Smalltalk Users, click here
> 
> .
> NAML
> 
>




--
View this message in context: 
http://forum.world.st/Voyage-collecting-data-from-Mongo-tp4944784p4944953.html
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Re: [Pharo-users] Voyage - collecting data from Mongo

[Mark Rizun]

> Mark
> once you have a solution could you post it because I would like to add
> your question to the voyage chapter.
> stef
>

Sure thing, Stef.

Re: [Pharo-users] Voyage - collecting data from Mongo

[Stephane Ducasse]

Mark
once you have a solution could you post it because I would like to add your
question to the voyage chapter.
stef

On Sun, Apr 30, 2017 at 10:37 AM, Stephane Ducasse 
wrote:

> mark
>
> what is such collection?
>
> Stef
>
> On Fri, Apr 28, 2017 at 11:04 PM, Holger Freyther 
> wrote:
>
>>
>> > On 28. Apr 2017, at 14:27, Mark Rizun  wrote:
>> >
>> > Hi,
>>
>> Hi!
>>
>>
>> > Is it possible to retrieve data from Mongo collection if it was not
>> created
>> > via Voyage?
>> > Meaning that I do not have a class in Pharo that would correspond to
>> said
>> > collection (should I implement one?).
>>
>> Yes. But you probably need to customize a bit.
>>
>> 1.) Make sure you refer to the right collection...
>>
>> descriptionContainer
>> 
>> ^VOMongoContainer new
>> collectionName: 'yourExistingCollectionName'
>> yourself
>>
>>
>> 2.) For materialization.. you should at least have
>> _id (okay every entry does that)
>> VOMongoSerializer fieldVersion (#version on my old Voyage)
>> VOMongoSerializer fieldType (#instanceOf)
>>
>> and then things should work out. You can probably add #version and
>> #instanceOf to your existing objects?
>>
>>
>>
>> holger
>>
>
>

Re: [Pharo-users] Voyage - collecting data from Mongo

[Христина Михайлюк]

Hello, Holger!

When I'm using MongoTalk in Pharo 5 and MongoDB 3.4 I can only get a list
of existing databases, using command

Mongo default open databases.

But when I want to get some database's collection

(Mongo default open databaseNamed: 'SomeDatabase')
collectionAt:'SomeCollection'.

it returns nil to me, although there is this collection, with some data at
MongoDB.

But when I'm using MongoTalk in Pharo 5  with MongoDB storage for example
2.6 version everything works fine.
Even at Pharo 5.0, there are built-in Mongo Browser and it gives the same
result - show the only list of databases.
What it the problem? Am I doing something wrong?

Thanks, Khrystyna.

2017-04-30 12:27 GMT+03:00 Holger Freyther :

>
> > On 30. Apr 2017, at 11:18, Mark Rizun  wrote:
> >
> >
> >
>
>
> > Sorry, I wasn't very accurate in previous email.
> > Actually, my friend is using MongoTalk/Voyage, and she encountered a
> problem that it is not possible to work with databases created in 3.0+
> versions of MongoDB.
> > Probably this issue is related to new storage types (connection part is
> fine).
>
> I am running a Pharo3.0 image (with an older Voyage) against MongoDB 3.2.
> I think I am already using "WiredTiger" as database. If you can reproduce
> it, we can have a look. The only issue I have seen is Sabines
> authentication failure with more "modern" schemes.
>
> holger
>

Re: [Pharo-users] Voyage - collecting data from Mongo

[Mark Rizun]

I am running a Pharo3.0 image (with an older Voyage) against MongoDB 3.2. I
think I am already using "WiredTiger" as database. If you can reproduce it,
we can have a look. The only issue I have seen is Sabines authentication
failure with more "modern" schemes.


I have Pharo 6 and the newest Voyage + MongoDB 3.4. I successfully
connected and was able to add new collections. The only problem was that I
couldn't access existing collections created in MongoDB.
I don't have access to my computer at the moment, but I will try your first
suggestion and let you know how it goes.

Re: [Pharo-users] Voyage - collecting data from Mongo

[Holger Freyther]

> On 30. Apr 2017, at 11:18, Mark Rizun  wrote:
> 
> 
> 


> Sorry, I wasn't very accurate in previous email.
> Actually, my friend is using MongoTalk/Voyage, and she encountered a problem 
> that it is not possible to work with databases created in 3.0+ versions of 
> MongoDB. 
> Probably this issue is related to new storage types (connection part is fine).

I am running a Pharo3.0 image (with an older Voyage) against MongoDB 3.2. I 
think I am already using "WiredTiger" as database. If you can reproduce it, we 
can have a look. The only issue I have seen is Sabines authentication failure 
with more "modern" schemes.

holger

Re: [Pharo-users] Voyage - collecting data from Mongo

[Mark Rizun]

oh? Is that written somewhere in the Voyage documentation?


Sorry, I wasn't very accurate in previous email.
Actually, my friend is using MongoTalk/Voyage, and she encountered a
problem that it is not possible to work with databases created in 3.0+
versions of MongoDB.
Probably this issue is related to new storage types (connection part is
fine).

 MongoDB wire protocol is upwards compatible, so while one might not use
the new features yet, your application will work.


OK

Re: [Pharo-users] Voyage - collecting data from Mongo

[Holger Freyther]

> On 30. Apr 2017, at 10:47, Mark Rizun  wrote:
> 
> Hi,

Hi!


> Holger, thank you, I will try your suggestion. 
> However, I use MongoDB 3.4, and I think that Voyage has support for only 
> versions under 3.0. Am I right?

oh? Is that written somewhere in the Voyage documentation? The MongoDB wire 
protocol is upwards compatible, so while one might not use the new features 
yet, your application will work.

holger

Re: [Pharo-users] Voyage - collecting data from Mongo

[Mark Rizun]

Hi,

Holger, thank you, I will try your suggestion.
However, I use MongoDB 3.4, and I think that Voyage has support for only
versions under 3.0. Am I right?

Stef, collection in mongo is a container for documents. For example, here
three documents are inserted in collection "inventory":

db.inventory.insertMany([
   { item: "journal", qty: 25, tags: ["blank", "red"], size: { h: 14, w:
21, uom: "cm" } },
   { item: "mat", qty: 85, tags: ["gray"], size: { h: 27.9, w: 35.5, uom:
"cm" } },
   { item: "mousepad", qty: 25, tags: ["gel", "blue"], size: { h: 19, w:
22.85, uom: "cm" } }
])
https://docs.mongodb.com/manual/tutorial/insert-documents/

Mark

2017-04-30 10:37 GMT+02:00 Stephane Ducasse :

> mark
>
> what is such collection?
>
> Stef
>
> On Fri, Apr 28, 2017 at 11:04 PM, Holger Freyther 
> wrote:
>
>>
>> > On 28. Apr 2017, at 14:27, Mark Rizun  wrote:
>> >
>> > Hi,
>>
>> Hi!
>>
>>
>> > Is it possible to retrieve data from Mongo collection if it was not
>> created
>> > via Voyage?
>> > Meaning that I do not have a class in Pharo that would correspond to
>> said
>> > collection (should I implement one?).
>>
>> Yes. But you probably need to customize a bit.
>>
>> 1.) Make sure you refer to the right collection...
>>
>> descriptionContainer
>> 
>> ^VOMongoContainer new
>> collectionName: 'yourExistingCollectionName'
>> yourself
>>
>>
>> 2.) For materialization.. you should at least have
>> _id (okay every entry does that)
>> VOMongoSerializer fieldVersion (#version on my old Voyage)
>> VOMongoSerializer fieldType (#instanceOf)
>>
>> and then things should work out. You can probably add #version and
>> #instanceOf to your existing objects?
>>
>>
>>
>> holger
>>
>
>

Re: [Pharo-users] Voyage - collecting data from Mongo

[Stephane Ducasse]

mark

what is such collection?

Stef

On Fri, Apr 28, 2017 at 11:04 PM, Holger Freyther 
wrote:

>
> > On 28. Apr 2017, at 14:27, Mark Rizun  wrote:
> >
> > Hi,
>
> Hi!
>
>
> > Is it possible to retrieve data from Mongo collection if it was not
> created
> > via Voyage?
> > Meaning that I do not have a class in Pharo that would correspond to said
> > collection (should I implement one?).
>
> Yes. But you probably need to customize a bit.
>
> 1.) Make sure you refer to the right collection...
>
> descriptionContainer
> 
> ^VOMongoContainer new
> collectionName: 'yourExistingCollectionName'
> yourself
>
>
> 2.) For materialization.. you should at least have
> _id (okay every entry does that)
> VOMongoSerializer fieldVersion (#version on my old Voyage)
> VOMongoSerializer fieldType (#instanceOf)
>
> and then things should work out. You can probably add #version and
> #instanceOf to your existing objects?
>
>
>
> holger
>

Re: [Pharo-users] Voyage - collecting data from Mongo

[Holger Freyther]

> On 28. Apr 2017, at 14:27, Mark Rizun  wrote:
> 
> Hi,

Hi!


> Is it possible to retrieve data from Mongo collection if it was not created
> via Voyage?
> Meaning that I do not have a class in Pharo that would correspond to said
> collection (should I implement one?).

Yes. But you probably need to customize a bit.

1.) Make sure you refer to the right collection...

descriptionContainer

^VOMongoContainer new
collectionName: 'yourExistingCollectionName'
yourself


2.) For materialization.. you should at least have
_id (okay every entry does that)
VOMongoSerializer fieldVersion (#version on my old Voyage)
VOMongoSerializer fieldType (#instanceOf)

and then things should work out. You can probably add #version and #instanceOf 
to your existing objects?



holger

Re: [Pharo-users] Voyage and attributes references

[Norbert Hartl]

> Am 06.04.2017 um 18:41 schrieb Hilaire :
> 
> Le 06/04/2017 à 16:14, Norbert Hartl a écrit :
>>> One idea will be to have collection of Address, but this really looks
>>> strange to me.
>>> 
>> why?
>> 
> 
> It looks like a painful scenario: Address is most of the time referenced
> by only one object, but in one scenario I need a shared attributes.
> Because of this it implies to overlook for #save and #remove messages to
> Address instances all around, forgetting some leading to bugs. But there
> are not alternative I guess? Or to have two Address class, one set as a
> root. Not sure what is the best practice.
> 
Not sure either. But I think having a SharedAddress class is worth a try. The 
other possibility would be if #voyageRoot would be also instance side. Right 
now I don't have a computer to check.

Norbert
> Hilaire
> 
> -- 
> Dr. Geo
> http://drgeo.eu
> 
> 

Re: [Pharo-users] Voyage and attributes references

[Hilaire]

Le 06/04/2017 à 16:14, Norbert Hartl a écrit :
>> One idea will be to have collection of Address, but this really looks
>> strange to me.
>>
> why?
> 

It looks like a painful scenario: Address is most of the time referenced
by only one object, but in one scenario I need a shared attributes.
Because of this it implies to overlook for #save and #remove messages to
Address instances all around, forgetting some leading to bugs. But there
are not alternative I guess? Or to have two Address class, one set as a
root. Not sure what is the best practice.

Hilaire

-- 
Dr. Geo
http://drgeo.eu

Re: [Pharo-users] Voyage and attributes references

[Norbert Hartl]

Hi,

> Am 06.04.2017 um 15:54 schrieb Hilaire :
> 
> Hi,
> 
> Here is another scenario where I have trouble with Voyage:
> 
> Let's an object A, with an attribute an object Address.
> Then I create B, a copy of A.
> 
> Of course the object Address is both an attribute of A and B. (no deep
> copy).
> 
> As long as my Voyage repo is running, editing Address from A or B is
> doing fine: when editing Address from A, I can see this reflected in B's
> Address, as expected.
> 
> Sadly, this Object scheme is lost in the persistency: when I reset the
> repo, shutdown it, restart it, to force a full retrieve from the Mongo
> repo, object A and B do not share anymore the Address object has it
> should be.
> 
> I understand Voyage is not a true really Object Oriented repository, but
> is it possible to overcome such limitation?
> 
The Adress object must voyageRoot in order for this to work. If an object is 
voyageRoot it is kept as identity being a separate object living in a 
collection that can be referenced. If it is not voyageRoot you store a copy of 
the object each them because that object gets embedded into the container 
object. 

> One idea will be to have collection of Address, but this really looks
> strange to me.
> 
why?

> I think Fuel was doing just fine with such scenario, but sadly Fuel is
> not reliable between images.
> 
Fuel stores the object graph as it is. It is hard to compare because you cannot 
search a fuel dump. I think the question is what you need. If it is having a 
partial graph in memory that has been extracted from the whole graph through 
query then you have a pretty decent need for a database and a tool like voyage. 
If you just need to persist you are better off with fuel. And if you need the 
same to be reliable between two images use STON.

> Thanks to read up to here.
> 
You're welcome! :)

Norbert

> Hilaire
> 
> -- 
> Dr. Geo
> http://drgeo.eu
> 
> 

Re: [Pharo-users] Voyage, DateAndTime and UTC

[Hilaire]

Based on the Paul suggestion, one can write a description to get
DateAndTime right.
Hopefully this could be fixed in Voyage

Hilarie


mongoAccesstime

^ VOToOneDescription new
attributeName: 'accessTime';
accessor: (MAPluggableAccessor
read: [:userClient| userClient accessTime printString]
write: [:userClient :string | userClient accessTime: 
(DateAndTime
fromString: string)]);
yourself

Le 31/03/2017 à 21:06, Hilaire a écrit :
> Thanks for the idea.
> For me it is a bug[2], like the other one related to Date persistency,
> saved as DateAndTime, then shifting you one day[1].

-- 
Dr. Geo
http://drgeo.eu

Re: [Pharo-users] Voyage, DateAndTime and UTC

[Paul DeBruicker]

Or just store as ISO8601 string.






NorbertHartl wrote
> Hi,
> 
>> Am 31.03.2017 um 17:16 schrieb Hilaire 

> hilaire@

> :
>> 
>> Hi,
>> 
>> As far as I see when I store a DateAndTime with local time,
>> "2017-03-31T17:10:46.137086+02:00", then I fetch it back, I got an UTC
>> DateAndTime  "2017-03-31T15:10:46.137086+00:00".
>> 
>> Am I doing something wrong or do I need to use a mongo description to
>> correct that. But wait, even so, I will not know what was the initial
>> local time.
>> 
>> How do you usually deal such issue?
>> 
> it's a pitty. BSON only supports a date type which is date and time in
> UTC. So the offset information is stripped off and that is the reason why
> you get it this way. I fell over this a lot. Especially when you use a
> local midnight DateAndTime store it in mongo, read it and then do #asDate
> you will end up having one day before. Very annoying.
> I think we shouldn't store DateAndTime as BSON date. We should create a
> custom type that includes timezone offset information.
> 
> Norbert





--
View this message in context: 
http://forum.world.st/Voyage-DateAndTime-and-UTC-tp4940779p4940811.html
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Re: [Pharo-users] Voyage, DateAndTime and UTC

[Norbert Hartl]

Hi,

> Am 31.03.2017 um 17:16 schrieb Hilaire :
> 
> Hi,
> 
> As far as I see when I store a DateAndTime with local time,
> "2017-03-31T17:10:46.137086+02:00", then I fetch it back, I got an UTC
> DateAndTime  "2017-03-31T15:10:46.137086+00:00".
> 
> Am I doing something wrong or do I need to use a mongo description to
> correct that. But wait, even so, I will not know what was the initial
> local time.
> 
> How do you usually deal such issue?
> 
it's a pitty. BSON only supports a date type which is date and time in UTC. So 
the offset information is stripped off and that is the reason why you get it 
this way. I fell over this a lot. Especially when you use a local midnight 
DateAndTime store it in mongo, read it and then do #asDate you will end up 
having one day before. Very annoying.
I think we shouldn't store DateAndTime as BSON date. We should create a custom 
type that includes timezone offset information.

Norbert

Re: [Pharo-users] Voyage Timeout

[Hilaire]

Indeed. It was just I was in the middle of something.

Le 25/03/2017 à 19:10, Stephane Ducasse a écrit :
> you should think to move to Pharo 50. We closed around 1500 issues between 
> pharo 40 and pharo 50 and the same amount between pharo 50 and pharo 60. 
> Pharo 50 is really stable and working well

-- 
Dr. Geo
http://drgeo.eu

Re: [Pharo-users] Voyage Timeout

[Stephane Ducasse]

Hilaire

you should think to move to Pharo 50. We closed around 1500 issues between
pharo 40 and pharo 50 and the same amount between pharo 50 and pharo 60.
Pharo 50 is really stable and working well
Stef


On Sat, Mar 25, 2017 at 8:58 AM, Hilaire  wrote:

> Hi Sabine,
>
> Thanks to share your experience.
>
> My process is in 3 folds:
>
> 1. I build from bash and smalltalk scripts an application archive for
> deployment, as I do for Dr.Geo (with configured image, VM, bootstart
> data and bash scripts)
>
> 2. On the target host, the archive is deployed (unarchived), then bash
> script launches the image for application installation (Mongo repo build
> up and filled with data). The image is not saved.
>
> 3. The image is launched again with a configured smalltalk script, then
> saved at the end. It should result in image to run the application,
> hopefully for multiple running instance with load balancing (not there
> yet).
>
> The 3. does not get well. As you suggested from your response, I will
> try to use the 'eval' command handler instead of the 'st' command
> handler and see how it goes.
>
> Thanks
>
> Hilaire
>
>
> Le 25/03/2017 à 07:55, Sabine Manaa a écrit :
> > Hi Hilaire,
> >
> > I also use a command line handler for start in a new image with voyage .
> > I start it like this on windows:
> >
> > .\...\Pharo5.0.image --no-default-preferences eval --save "
> > MCRepositoryGroup default addRepository: (MCHttpRepository location:
> > 'http://smalltalkhub.com/mc/Sabine/RKA24/main'  user: 'Sabine'
> >  password: 'xxx').Metacello new smalltalkhubUser: 'Sabine' project:
> > 'RKA24'; configuration: 'RKA24'; version: #development; load".
> >
> > Are you sure that the code in the file is executed? I had similar
> > problems and asked in slack. Unfortunately the discussion is gone. It
> > came out that some combinations of file configuration and command line
> > commands do not work. I currently don't remember which (save?) but
> > perhaps this brings you to an idea.
> >
> > Regards
> > Sabine
>
> --
> Dr. Geo
> http://drgeo.eu
>
>
>

Re: [Pharo-users] Voyage Timeout

[Hilaire]

Hi Sabine,

Thanks to share your experience.

My process is in 3 folds:

1. I build from bash and smalltalk scripts an application archive for
deployment, as I do for Dr.Geo (with configured image, VM, bootstart
data and bash scripts)

2. On the target host, the archive is deployed (unarchived), then bash
script launches the image for application installation (Mongo repo build
up and filled with data). The image is not saved.

3. The image is launched again with a configured smalltalk script, then
saved at the end. It should result in image to run the application,
hopefully for multiple running instance with load balancing (not there yet).

The 3. does not get well. As you suggested from your response, I will
try to use the 'eval' command handler instead of the 'st' command
handler and see how it goes.

Thanks

Hilaire


Le 25/03/2017 à 07:55, Sabine Manaa a écrit :
> Hi Hilaire,
> 
> I also use a command line handler for start in a new image with voyage .
> I start it like this on windows:
> 
> .\...\Pharo5.0.image --no-default-preferences eval --save "
> MCRepositoryGroup default addRepository: (MCHttpRepository location:
> 'http://smalltalkhub.com/mc/Sabine/RKA24/main'  user: 'Sabine'
>  password: 'xxx').Metacello new smalltalkhubUser: 'Sabine' project:
> 'RKA24'; configuration: 'RKA24'; version: #development; load".
> 
> Are you sure that the code in the file is executed? I had similar
> problems and asked in slack. Unfortunately the discussion is gone. It
> came out that some combinations of file configuration and command line
> commands do not work. I currently don't remember which (save?) but
> perhaps this brings you to an idea.
> 
> Regards
> Sabine

-- 
Dr. Geo
http://drgeo.eu

Re: [Pharo-users] Voyage Timeout

[Sabine Manaa]

Hi Hilaire,

I also use a command line handler for start in a new image with voyage . I
start it like this on windows:

.\...\Pharo5.0.image --no-default-preferences eval --save "
MCRepositoryGroup default addRepository: (MCHttpRepository location: '
http://smalltalkhub.com/mc/Sabine/RKA24/main'  user: 'Sabine'  password:
'xxx').Metacello new smalltalkhubUser: 'Sabine' project: 'RKA24';
configuration: 'RKA24'; version: #development; load".

Are you sure that the code in the file is executed? I had similar problems
and asked in slack. Unfortunately the discussion is gone. It came out that
some combinations of file configuration and command line commands do not
work. I currently don't remember which (save?) but perhaps this brings you
to an idea.

Regards
Sabine


2017-03-24 20:51 GMT+01:00 HilaireFernandes [via Smalltalk] <
ml-node+s1294792n4939873...@n4.nabble.com>:

If I open manualy this image execute the configureMyImage.st code from a
playground, then save the image, I don't have a Voyage time error at
start up.

Are there non friendly interaction between voyage/socket and st command
handler?

Hilaire

Le 22/03/2017 à 20:35, Hilaire a écrit :

> Hi,
>
> When I configure a production image with command st handler as following:
>
> pharo myImage st --save --quit configureMyImage.st
>
> I notice at image start up, a Socket timeout error.
>
> In the configureMyImage.st script, among other things, I open a
> singleton Voyage repository. I added a 5s delay at the end of this
> script, just wondering if image was shutdown before Voyage establishes
> connection with the Mongo DB, but no.
>
> Any incompatibility issues to be aware of between st command handler
> (particularly the --save part) and Voyage repository?
>
> Thanks,
> Hilaire

-- 
Dr. Geo
http://drgeo.eu


http://drgeo.eu


--
If you reply to this email, your message will be added to the discussion
below:
http://forum.world.st/Voyage-Timeout-tp4939672p4939873.html
To start a new topic under Pharo Smalltalk Users, email
ml-node+s1294792n1310670...@n4.nabble.com
To unsubscribe from Pharo Smalltalk Users, click here

.
NAML





--
View this message in context: 
http://forum.world.st/Voyage-Timeout-tp4939672p4939905.html
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Re: [Pharo-users] Voyage Timeout

[Hilaire]

If I open manualy this image execute the configureMyImage.st code from a
playground, then save the image, I don't have a Voyage time error at
start up.

Are there non friendly interaction between voyage/socket and st command
handler?

Hilaire

Le 22/03/2017 à 20:35, Hilaire a écrit :
> Hi,
> 
> When I configure a production image with command st handler as following:
> 
> pharo myImage st --save --quit configureMyImage.st
> 
> I notice at image start up, a Socket timeout error.
> 
> In the configureMyImage.st script, among other things, I open a
> singleton Voyage repository. I added a 5s delay at the end of this
> script, just wondering if image was shutdown before Voyage establishes
> connection with the Mongo DB, but no.
> 
> Any incompatibility issues to be aware of between st command handler
> (particularly the --save part) and Voyage repository?
> 
> Thanks,
> Hilaire

-- 
Dr. Geo
http://drgeo.eu

Re: [Pharo-users] Voyage and Date

[Hilaire]

  
  
Hi, 

Bellow a digest I compiled regarding problems met with Voyage,
  and its resolutions, all documented  through messages in the
  mailing list (hello Slat ;)

Hilaire

Le 05/03/2017 à 09:49, Hilaire a
  écrit :


  Hi Stephan,

I am maintaining such a digest, with links to the discussion on the
list. I will post it once I am done with Voyage.

Hilaire


Voyage
Feedback on its
  installation and use:

  MongoDB get installed and running easily


  Get a hard time installing it from the official configuration
browser, it required an update to Seaside which in turn does not
work. Fight for a couple of days to get it installed.http://forum.world.st/Latest-Voyage-for-Pharo4-tp4934769p4935335.html


  Got hanging Voyage, need to use the latest version and not the
one from the Configuration browser http://forum.world.st/Voyage-hang-tp4935341.html


  Instance will not synchronize between several Voyage
repository: you need to stick to one repo or use id to link data
between repo, like good old Sql http://forum.world.st/Voyage-Unique-vs-Multiple-repo-tt4935133.html


  Get back an object to its repository value, not sure about
this one http://forum.world.st/Voyage-refreshing-an-object-back-to-its-repository-state-tp4935881.html


  Have difficulties to iterate over a fetched object attributes,
to me Voyage does not behave as expected http://forum.world.st/Voyage-and-instances-retrieving-tt4936868.html.
Here is a test to expose the problem http://forum.world.st/Test-for-Voyage-failure-to-materialize-in-some-situation-tt4938014.html


  Got a one day shift when saving/loading a date http://forum.world.st/Voyage-and-Date-tp4937235.html


  Meet broken class, not sure what it is about http://forum.world.st/Voyage-VOToOneDescription-or-VOMongoToOneDescription-tp4936998.html


  Association and dictionary need to be on elementary form with
key a string and value a numeric, otherwise you can not save it.
There is a work around http://forum.world.st/Voyage-and-Association-tt4936673.html#a4936694


  Scaled Decimal will mostly not be persisted. If you are doing
arithmetic computing and exact value is needed, you will end
with a too large integer error from Voyage (for the fraction
den/num representing your exact value). You have no choice but
to use float http://forum.world.st/Voyage-and-Scaled-decimal-tt4936625.html


  Voyage singleton repository and Seaside are reported to work
together just fine http://forum.world.st/Voyage-and-seaside-tt4935946.html


  When editing and saving a client model, I got a duplicated
object in the Participant collection. http://forum.world.st/Voyage-and-duplicated-entry-tt4937268.html


  You need an adaptor for your Date attributes: to convert back
from the DateAndTime saved form in Mongo http://forum.world.st/Voyage-save-Date-get-back-DateAndTime-bug-tt4703601.html,
but there is issue with a shifted date of one day, really!?


-- 
Dr. Geo
http://drgeo.eu
  

Re: [Pharo-users] Voyage and Date

[stepharong]

On Sun, 05 Mar 2017 09:49:02 +0100, Hilaire  wrote:


Hi Stephan,

I am maintaining such a digest, with links to the discussion on the
list. I will post it once I am done with Voyage.


super cool


Hilaire

Le 04/03/2017 à 21:34, stepharong a écrit :

I would love to have a digest of the problems you encountered and the
solution.
Because like that we could write a better documentation.

I cannot because I do not face the problems (since I'm not developing
real apps for lack of time/concentration).






--
Using Opera's mail client: http://www.opera.com/mail/

Re: [Pharo-users] Voyage and instances retrieving

[Hilaire]

I'll make a test case to illustrate the issue.

Hilaire

Le 06/03/2017 à 19:05, Esteban Lorenzano a écrit :
>> Ah, sorry I was not clear enough in my introduction. Obviously, I
>> removed all =/hash overrides on the involved objects and it is therefore
>> an orthogonal issue (that's why I first resolved the other issues
>> first). Or did you mean something I did not understand in your previous
>> message?
> no, I didn’t understood you removed #= and #hash :)
> 

-- 
Dr. Geo
http://drgeo.eu

Re: [Pharo-users] Voyage and instances retrieving

[Esteban Lorenzano]

> On 6 Mar 2017, at 18:56, Hilaire  wrote:
> 
> Ah, sorry I was not clear enough in my introduction. Obviously, I
> removed all =/hash overrides on the involved objects and it is therefore
> an orthogonal issue (that's why I first resolved the other issues
> first). Or did you mean something I did not understand in your previous
> message?

no, I didn’t understood you removed #= and #hash :)

> 
> Hilaire
> 
> Le 06/03/2017 à 18:45, Esteban Lorenzano a écrit :
>> just as a side note: 
>> 
>> you must NEVER do a hash based in an attribute that might change. You will 
>> screw not just Voyage but all collections where your object is stored 
>> (except Array). 
>> 
>> Esteban
> 
> -- 
> Dr. Geo
> http://drgeo.eu
> 
> 

Re: [Pharo-users] Voyage and instances retrieving

[Hilaire]

Ah, sorry I was not clear enough in my introduction. Obviously, I
removed all =/hash overrides on the involved objects and it is therefore
an orthogonal issue (that's why I first resolved the other issues
first). Or did you mean something I did not understand in your previous
message?

Hilaire

Le 06/03/2017 à 18:45, Esteban Lorenzano a écrit :
> just as a side note: 
> 
> you must NEVER do a hash based in an attribute that might change. You will 
> screw not just Voyage but all collections where your object is stored (except 
> Array). 
> 
> Esteban

-- 
Dr. Geo
http://drgeo.eu

Re: [Pharo-users] Voyage and instances retrieving

[Esteban Lorenzano]

just as a side note: 

you must NEVER do a hash based in an attribute that might change. You will 
screw not just Voyage but all collections where your object is stored (except 
Array). 

Esteban

> On 6 Mar 2017, at 18:34, Hilaire  wrote:
> 
> Le 03/03/2017 à 18:09, Hilaire a écrit :
>> I will try to dig for more clues.
> 
> Now that I clarified the issues regarding duplicated entries and Date. I
> took another look to this problem.
> 
> After reset of the repo, to test for sure Voyage correctly retrieves the
> attributes,  I face the same issue again. The attributes of an object,
> itself a collection attribute of an object in the repo, are not
> materialized.
> 
> The code bellow does not work as expected. Some details on the involved
> object:
> someAdults is a collection of adult objects (saved in their own
> Participant collection in the repo and already retrieved);  expenses is
> an attribute of a Contract instance (the later save in its own
> collection too); owner returns an adult,and I think it is the one that
> does not materialize.
> 
>> expensesOf: someAdults
>>   ^ expenses select: [ :anExpense | someAdults includes: anExpense owner]
> 
> 
> Voyage appears to be lazy to materialize it, and indeed the changed code
> bellow makes the materialization to take place:
> 
> 
>> expensesOf: someAdults
>>   ^ expenses select: [ :anExpense | someAdults includes: anExpense owner 
>> value ]
> 
> Of course it can't be a solution because I will not know for sure when
> selection will work or fail. So far I only see the problem in two
> places, and I have a lot of selection code.
> 
> Hilaire
> 
> -- 
> Dr. Geo
> http://drgeo.eu
> 
> 

Re: [Pharo-users] Voyage and instances retrieving

[Hilaire]

Le 03/03/2017 à 18:09, Hilaire a écrit :
> I will try to dig for more clues.

Now that I clarified the issues regarding duplicated entries and Date. I
took another look to this problem.

After reset of the repo, to test for sure Voyage correctly retrieves the
attributes,  I face the same issue again. The attributes of an object,
itself a collection attribute of an object in the repo, are not
materialized.

The code bellow does not work as expected. Some details on the involved
object:
someAdults is a collection of adult objects (saved in their own
Participant collection in the repo and already retrieved);  expenses is
an attribute of a Contract instance (the later save in its own
collection too); owner returns an adult,and I think it is the one that
does not materialize.

> expensesOf: someAdults
>^ expenses select: [ :anExpense | someAdults includes: anExpense owner]


Voyage appears to be lazy to materialize it, and indeed the changed code
bellow makes the materialization to take place:


> expensesOf: someAdults
>^ expenses select: [ :anExpense | someAdults includes: anExpense owner 
> value ]

Of course it can't be a solution because I will not know for sure when
selection will work or fail. So far I only see the problem in two
places, and I have a lot of selection code.

Hilaire

-- 
Dr. Geo
http://drgeo.eu

Re: [Pharo-users] Voyage and duplicated entry

[Norbert Hartl]

> Am 06.03.2017 um 18:10 schrieb jtuc...@objektfabrik.de:
> 
> Hilaire,
> 
> as soon as the hash of an object changes because you change an attribute that 
> is used in the hash function, the object is not identical to its older ego 
> any more, so Voyage cannot know it still is the same object (nor any other 
> caching solution).
> Or am I wrong about this whole hash/= thing?
> 
Yes :) You are mixing equality and identity. An object is identical if the 
memory location is the same. An object is equal whatever is defined in =/hash. 
In the default case classes do not overwrite =/hash so = and == return the same 
value. If you change the state of an object you might change the hash but not 
the identityHash. So it is identical but different to the version in the 
database hence should update the existing object and not creating a new one.

> The only thing I could imagine is that Voyage somewhere uses = where it 
> should use ==. But wouldn't many more people have problems then?
> 
The problem is that we often use equality based collections where we should use 
identity based ones. These problems are hidden because = and == are the same 
for normal classes. As soon as you overwrite =/hash you experience problems 
because of that. 

So I have the impression that in general overwriting =/hash is not a good idea. 
Most of the time you mean "equal regarding to some context". In this case it is 
better to have your own equality selector like #isSameX:, #hasSameX: etc. 
Because the kernel classes rely on = equality you tear the semantics apart if 
yoou overwrite.

Norbert

 
> Joachim
> 
> 
> 
> Am 06.03.17 um 18:03 schrieb Hilaire:
>> The more I think the more it seems wrong to me. Whenever you ask an
>> instance to save itself, if already in repo it should not duplicate
>> itself whenever hash/= is overrided in this object. It does not sound as
>> an expected behaviour.
>> 
>> Hilaire
>> 
>> Le 05/03/2017 à 14:51, Hilaire a écrit :
>>> Understood.
>>> My use/understanding of hash and =, true in DrGeo, was more like unique
>>> identifier regarding its ontological characteristics (what distinguish
>>> it from other). So an exact same Point in DrGeo will have different hash
>>> value depending on its position on the plane, or it being free on a
>>> line, etc.  May be I got it biased here.
>>> 
>>> Anyway problem solved, comparing protocol was just rampant code.
> 
> 
> -- 
> ---
> Objektfabrik Joachim Tuchel  mailto:jtuc...@objektfabrik.de 
> 
> Fliederweg 1 http://www.objektfabrik.de 
> 
> D-71640 Ludwigsburg  http://joachimtuchel.wordpress.com 
> 
> Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1

Re: [Pharo-users] Voyage and duplicated entry

[Norbert Hartl]

Hilaire,

I think you are right and I wonder why we didn't change it, yet. I can remember 
talking with Esteban about it. The culprit is that in VOCache the 
reversedObjects instance variable is a WeakKeyDictionary and not a 
WeakIdentityKeyDictionary. 
That is the reason why #isNew on an object returns true if equality is not the 
same. And this leads to object duplication. The whole purpose of the VOCache is 
to keep "identity" for the objects. So using an equality based collection is 
plain wrong.

Norbert

> Am 06.03.2017 um 18:03 schrieb Hilaire :
> 
> The more I think the more it seems wrong to me. Whenever you ask an
> instance to save itself, if already in repo it should not duplicate
> itself whenever hash/= is overrided in this object. It does not sound as
> an expected behaviour.
> 
> Hilaire
> 
> Le 05/03/2017 à 14:51, Hilaire a écrit :
>> Understood.
>> My use/understanding of hash and =, true in DrGeo, was more like unique
>> identifier regarding its ontological characteristics (what distinguish
>> it from other). So an exact same Point in DrGeo will have different hash
>> value depending on its position on the plane, or it being free on a
>> line, etc.  May be I got it biased here.
>> 
>> Anyway problem solved, comparing protocol was just rampant code.
> 
> -- 
> Dr. Geo
> http://drgeo.eu
> 
> 

Re: [Pharo-users] Voyage and duplicated entry

[jtuc...@objektfabrik.de]

What about a simple test?

Load one of those objects anad assign it to a variable. Then change one 
of ist values and check if the one you have now is still == the other.


..it's a bit hard to explain, but I guess you know what I mean.

Joachim

Am 06.03.17 um 18:03 schrieb Hilaire:

The more I think the more it seems wrong to me. Whenever you ask an
instance to save itself, if already in repo it should not duplicate
itself whenever hash/= is overrided in this object. It does not sound as
an expected behaviour.

Hilaire

Le 05/03/2017 à 14:51, Hilaire a écrit :

Understood.
My use/understanding of hash and =, true in DrGeo, was more like unique
identifier regarding its ontological characteristics (what distinguish
it from other). So an exact same Point in DrGeo will have different hash
value depending on its position on the plane, or it being free on a
line, etc.  May be I got it biased here.

Anyway problem solved, comparing protocol was just rampant code.



--
---
Objektfabrik Joachim Tuchel  mailto:jtuc...@objektfabrik.de
Fliederweg 1 http://www.objektfabrik.de
D-71640 Ludwigsburg  http://joachimtuchel.wordpress.com
Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1

Re: [Pharo-users] Voyage and duplicated entry

[jtuc...@objektfabrik.de]

Hilaire,

as soon as the hash of an object changes because you change an attribute 
that is used in the hash function, the object is not identical to its 
older ego any more, so Voyage cannot know it still is the same object 
(nor any other caching solution).

Or am I wrong about this whole hash/= thing?

The only thing I could imagine is that Voyage somewhere uses = where it 
should use ==. But wouldn't many more people have problems then?


Joachim



Am 06.03.17 um 18:03 schrieb Hilaire:

The more I think the more it seems wrong to me. Whenever you ask an
instance to save itself, if already in repo it should not duplicate
itself whenever hash/= is overrided in this object. It does not sound as
an expected behaviour.

Hilaire

Le 05/03/2017 à 14:51, Hilaire a écrit :

Understood.
My use/understanding of hash and =, true in DrGeo, was more like unique
identifier regarding its ontological characteristics (what distinguish
it from other). So an exact same Point in DrGeo will have different hash
value depending on its position on the plane, or it being free on a
line, etc.  May be I got it biased here.

Anyway problem solved, comparing protocol was just rampant code.



--
---
Objektfabrik Joachim Tuchel  mailto:jtuc...@objektfabrik.de
Fliederweg 1 http://www.objektfabrik.de
D-71640 Ludwigsburg  http://joachimtuchel.wordpress.com
Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1

Re: [Pharo-users] Voyage and duplicated entry

[Hilaire]

The more I think the more it seems wrong to me. Whenever you ask an
instance to save itself, if already in repo it should not duplicate
itself whenever hash/= is overrided in this object. It does not sound as
an expected behaviour.

Hilaire

Le 05/03/2017 à 14:51, Hilaire a écrit :
> Understood.
> My use/understanding of hash and =, true in DrGeo, was more like unique
> identifier regarding its ontological characteristics (what distinguish
> it from other). So an exact same Point in DrGeo will have different hash
> value depending on its position on the plane, or it being free on a
> line, etc.  May be I got it biased here.
> 
> Anyway problem solved, comparing protocol was just rampant code.

-- 
Dr. Geo
http://drgeo.eu

Re: [Pharo-users] Voyage and duplicated entry

[Hilaire]

Understood.
My use/understanding of hash and =, true in DrGeo, was more like unique
identifier regarding its ontological characteristics (what distinguish
it from other). So an exact same Point in DrGeo will have different hash
value depending on its position on the plane, or it being free on a
line, etc.  May be I got it biased here.

Anyway problem solved, comparing protocol was just rampant code.


Le 05/03/2017 à 12:52, Joachim Tuchel a écrit :
> Sounds like this has nothing to do with voyage. If you modify part of on 
> object's unique identifier, it's another object. The best you can do is to 
> use a synthetic id that has no business meaning and use that for object 
> identity.

-- 
Dr. Geo
http://drgeo.eu

Re: [Pharo-users] Voyage and duplicated entry

[Joachim Tuchel]

Hilaire

Sounds like this has nothing to do with voyage. If you modify part of on 
object's unique identifier, it's another object. The best you can do is to use 
a synthetic id that has no business meaning and use that for object identity.

Joachim

> Am 05.03.2017 um 12:02 schrieb Hilaire :
> 
> Situation looks a bit clearer.
> The duplicated object entries issue arises with two concomitant situations:
> 
> - the object reimplements hash and = methods
> - one of the attributes participating in the comparing protocol is modified.
> 
> In that scenario, Voyage guess it is dealing with a new element, even if
> it is not the case.
> 
> In some scenario, user really needs to override the comparing protocol,
> how to deal with the duplicated entries issue in that case?
> 
> Hilaire
> 
>> Le 05/03/2017 à 10:19, Hilaire a écrit :
>> I must stress the same instance duplication occurs when I inspect an
>> instance, edit one attribute from the inspector, then save it from the
>> inspector with "self save" command.
> 
> -- 
> Dr. Geo
> http://drgeo.eu
> 
> 
> 

Re: [Pharo-users] Voyage and duplicated entry

[Hilaire]

Situation looks a bit clearer.
The duplicated object entries issue arises with two concomitant situations:

- the object reimplements hash and = methods
- one of the attributes participating in the comparing protocol is modified.

In that scenario, Voyage guess it is dealing with a new element, even if
it is not the case.

In some scenario, user really needs to override the comparing protocol,
how to deal with the duplicated entries issue in that case?

Hilaire

Le 05/03/2017 à 10:19, Hilaire a écrit :
> I must stress the same instance duplication occurs when I inspect an
> instance, edit one attribute from the inspector, then save it from the
> inspector with "self save" command.

-- 
Dr. Geo
http://drgeo.eu

Re: [Pharo-users] Voyage and Date

[Esteban Lorenzano]

Voyage cannot guess user intentions. 
But yes we could add a helper to do the transformation easier (like a special 
description for dates), but you will always need to configure that by hand.

Esteban

> On 5 Mar 2017, at 10:22, Hilaire  wrote:
> 
> Hi Esteban,
> 
> This is a recurring problem. May be Voyage should come with the
> necessary adaptor to have the Date right. It is likely *every* Voyage
> user faces the problem, and it does not fell good about the framework to
> have issue on such elementary feature.
> 
> Hilaire
> 
> Le 05/03/2017 à 10:06, Esteban Lorenzano a écrit :
>> the base of the problem is that mongo does not actually has a Date type, 
>> just DateAndTime (even if is called Date). 
>> So if you want a Date, you need to do some conversion. 
> 
> -- 
> Dr. Geo
> http://drgeo.eu
> 
> 

Re: [Pharo-users] Voyage and Date

[Hilaire]

Hi Esteban,

This is a recurring problem. May be Voyage should come with the
necessary adaptor to have the Date right. It is likely *every* Voyage
user faces the problem, and it does not fell good about the framework to
have issue on such elementary feature.

Hilaire

Le 05/03/2017 à 10:06, Esteban Lorenzano a écrit :
> the base of the problem is that mongo does not actually has a Date type, just 
> DateAndTime (even if is called Date). 
> So if you want a Date, you need to do some conversion. 

-- 
Dr. Geo
http://drgeo.eu

Re: [Pharo-users] Voyage and duplicated entry

[Hilaire]

Hi Sabine, Norbert,

It is nice to have feedbacks from other Voyagers ;)

Thanks about the notice regarding reset on the repository.
It may have implication I should be careful about, but not in my
scenario because:

- I start with empty collections in the repository, for the model part,
- I import in the repository a model instance. The model instance comes
from a Fuel document,
- When I edit an instance (a person data), then save, I got a
supplementary entry in the repo.

No where in this scenario I execute a reset, at least from my code.

I must stress the same instance duplication occurs when I inspect an
instance, edit one attribute from the inspector, then save it from the
inspector with "self save" command.

Hilaire


Le 04/03/2017 à 12:21, Sabine Manaa a écrit :
> did you do VORepository current reset in the meantime?
> 
> If yes, this could be the reason. If you do this, the smalltalk  cache
> of the objects is reset and the next time the objects are loaded again
> from mongo and then they are no longer "the same" objects within
> smalltalk. I had a hard time to learn this. 

-- 
Dr. Geo
http://drgeo.eu

Re: [Pharo-users] Voyage and Date

[Esteban Lorenzano]

yes, this is a good solution. 

the base of the problem is that mongo does not actually has a Date type, just 
DateAndTime (even if is called Date). 
So if you want a Date, you need to do some conversion. 

Esteban

> On 4 Mar 2017, at 11:25, Hilaire  wrote:
> 
> Concerning this problem, one option I found is to get far away of the
> Voyage/Mongo Date/DateAndTime representation/conversion and stick to
> string, not really efficience, but well...
> 
> mongoBirthday
> 
> ^ VOToOneDescription new
>   attributeName: 'birthday';
>   accessor: (MAPluggableAccessor
>   read: [:person | person birthday ifNotNil: [person birthday 
> mmdd]]
>   write: [:person :string |string ifNotNil: [person birthday: 
> string
> asDate]]);
>   yourself
> 
> 
> Le 03/03/2017 à 21:12, Hilaire a écrit :
>> Not sure it is related to this:
>> http://forum.world.st/Possible-bug-with-Voyage-Mongo-date-tt4735597.html
> 
> -- 
> Dr. Geo
> http://drgeo.eu
> 
> 

Re: [Pharo-users] Voyage and Date

[Hilaire]

Hi Stephan,

I am maintaining such a digest, with links to the discussion on the
list. I will post it once I am done with Voyage.

Hilaire

Le 04/03/2017 à 21:34, stepharong a écrit :
> I would love to have a digest of the problems you encountered and the
> solution.
> Because like that we could write a better documentation.
> 
> I cannot because I do not face the problems (since I'm not developing
> real apps for lack of time/concentration). 
> 

-- 
Dr. Geo
http://drgeo.eu