[bug report 2040] Vserver, NOTE 2. HOW TO write client/server apps

[Ruslan Zasukhin]

On 12/06/12 8:37 PM, "Charles Yeomans" <charles at declareSub.com> wrote:

>> 1) Agree this is quite natural from OO point of view design
>> 
>>     object1.open
>>             object2.open()
>> 
>>             object2.close()
>>     object1.close
>> 
>> Looking on this abstract notation, anybody will expect that
>> object2, which
>> is LOWER by hierarchy will close object1? Of course not!
>> 
>> Does this clean explanation?
> 
>  From an OO point of design as presented in, say, Stroustrup's "The C+
> + Programming Language", I would expect that the VConnection
> destructor would close the connection.

AGREE. So the same must do code as

>>     object1.open
>>             object2.open()
>> 
>>             object2.close()
       object1 = nil

Ivan, I believe this works in our case, right ?

--------------- 
> VConnection was just introduced in 2.4b15, so what I think is that
> the interaction between VConnection and VDatabase is not well-thought
> yet. For example, the documentation for VDatabase says this about its
> VConnection constructor.
> 
> "You need the second form to create a VDatabase object to access a
> remote database.
> It does not establish a connection, but just stores parameters that
> will be used later. The
> connection is established on a call of either Open()  or Create(). "

> In fact this is not true, as the crash log provided with bug #2041
> shows.  The constructor code attempts a connection to the server.

Argh, this is out of date text.
Must be fixed.
Kirill
 

---------- 
> Here is the way I think the interaction should work.
> 
> Create VConnection object.
> 
> Calling VConnection.Open should be possible, but optional.

NO. 

This is VERY REQUIRED step in the current model/technology.
This cannot be changed.

> VDatabase.Constructor(connection as VConnection) should behave as you
> describe above.  Right now, V4Rb registers a "null" database with the
> server.

No, it will not behave in this way.
 
> Also, passing a nil connection object to VDatabase.Constructor
> results in a crash (bug #2042).  Correct behavior should be to raise
> an exception.

FIXED

> VDatabase.Open should call VConnection.Open; testing suggests that
> VConnection.Open is a no-op if the connection object has already been
> opened.

NO, again, we cannot do this.

Because we need already opened connection when we start construct database
object. This process ALREADY communicate with server.
 
> VDatabase.Close should not call VConnection.Close, because it does
> not and should not know whether other VDatabase objects are using the
> same connection.

right
 
> VConnection.Close should call VDatabase.Close for every database
> using that connection.

In fact when you CLOSE connection, then on server side all right,
On client side - all db/cursor objects that you have create in scope of this
connection become INVALID. You should not touch them.

So virtually YES, connection.close -> kill all its objects.
 
> VConnection.Destructor should call VConnection.Close.

AGREE. Ivan please confirm this.
 
> And perhaps VConnection should allow us to see the list of databases
> using the connection.

May be...

-- 
Best regards,

Ruslan Zasukhin
VP Engineering and New Technology
Paradigma Software, Inc

Valentina - Joining Worlds of Information
http://www.paradigmasoft.com

[I feel the need: the need for speed]