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

[Charles Yeomans]

On Dec 12, 2006, at 4:52 AM, Ruslan Zasukhin wrote:

> Hi All,
> Hi Charles,
>
> In 2040 bug report Charles have write:
>
>>   dim connection as new VConnection("localhost", "sa", "sa")
>>   connection.Open
>>
>>   dim db as new VDatabase(connection)
>>   db.Open new FolderItem("testDB")
>>   db.Close
>
> And connection still is not closed.
>
> May be this was result of my own confusing message...
> But in short:
>     this is correct.
>     DEVELOPER self must do  connection.close()
>
> 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.

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.

Here is the way I think the interaction should work.

Create VConnection object.

Calling VConnection.Open should be possible, but optional.

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

Also, passing a nil connection object to VDatabase.Constructor  
results in a crash (bug #2042).  Correct behavior should be to raise  
an exception.


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

VDatabase.Close should not call VConnection.Close, because it does  
not and should not know whether other VDatabase objects are using the  
same connection.

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

VConnection.Destructor should call VConnection.Close.

And perhaps VConnection should allow us to see the list of databases  
using the connection.



Charles Yeomans