Version 2

[Jochen Peters]

Hi Ruslan,

>> Let me recall:
>>
>> Your approach (and also my first approach) was to store all this stuff
>> INSIDE the Valentina database. (For example using System Tables)
>>
>> Let us discuss the Pro's and Contra's of this approach
>>
>> Pro's
>> ------
>>
>> 1) All stuff is safely inside the database - when the user moves the
>> database then he will still have all it's database preferences - like
>> for example the column width in the Databrowser.
>>
>> Well - i really see only this one advantage :-) Please let me know
>> if you see anymore.
>>
>> Contra's
>> --------
>>
>> 1) This approach does not work for other databases we can use with 
>> vStudio
>>  via ODBC.
>
> yes
>
>> 2) Developers often want's to trash their db to start a fresh one - 
>> with
>>  this approach all preferences will be lost, too. (Can be very bad
>>  if you have defined several individual columns widths for the
>>  databrowser.)
>
> But how you going relate later preferences of _deleted_ database
> To new one ?
Well - very simple approach is that vStudio will guess that the 
structure
of the database will be the same (for the trashed and the new db).
AND: vStudio can safely IGNORE (or delete) preferences that makes no 
sense
any more (for example the column width's of a deleted table)
We are talking about non critical preferences here! So ignoring or 
deleting preferences
is a safe operation...


>
> Well, this can be implemented as idea of STYLES in PageMaker/inDesign!
This goes one step further! And yes! It is a good idea!
>
>
>> 3) This will also mean that vStudio will ALWAYS change a user's 
>> database
>>  writing own stuff into it! I think this is very bad idea!
>
> May be
>
>> Having a seperate storage file (of course this will also be a 
>> Valentina
>> database with a different extension) we do not have this 
>> disadvantages!
>
> One more file?   .gui ?  :-)
> Interesting idea.
>
> But note, in Valentina use CAN say that all files must be in one 
> physical.
>
>> I see only advantages for this approach:
>> 1) We do not touch a users database! We can even open a read-only 
>> database
>>  and are still able to save preferences!
>
> Yes.
>
> So do you mean that EACH Valentina db must get own such file?
> I think yes.
Yes! We will simply have one more file - for example with extension 
.gui.
There is NO NEED for V4MD or V4RB developers to distribute this file 
with their solution!
This is another advantage.

>
> Or you mean that Valentina Studio should maintain own single file to 
> keep
> prefs for all dbs it have open? I think NO.
NO!
>
>> 2) We can save this preferences LOCALY for server database! (and of 
>> course
>>  the preference db can be also a server db, if needed!)
>
> Yes.
>
>> 3) During development you can safely trash your db without loosing any
>>  preferences!
>
> This is not usual behavior for other Valentina files. But why not.
> So I have
>
>     db.vdb, db.dat, db.ind, db.gui
Exactly!

>
> I trash the first 4. Now I create new db with the same name,
> Valentina see that such file already exists in the folder and do not 
> erase
> .gui file. This is what you want ?
Yes - exactly!
I think 4D and Omnis are using the same approach.

>
>> 4) We currently recommend to use several files for security reasons - 
>> so
>> it does not matter to have one more! AND: On Mac you can put all files
>> into
>> single PACKAGE (which i would RECOMMEND to implement for 2.x) - on 
>> Windows
>> you can store all files in single folder.
>
> Single folder can make developer and put db files there
Yes - but at least the Mac version of the kernel can put all requested 
files
into single Package! This is the Mac way! (This is comparable to the 
9.x variant to
store everything in one physical file - which is a much weaker 
approach..)

>
>> So - what you think?
>
> I think you should right now forward this letter to Valentina Studio 
> list
> and beta list for discussion. :-)
Done :-)

One more point:
Later we will be able to store Scripts and "Application Logic" using 
vStudio.
It is always a good idea to seperate this stuff from the data!

Thinking about the future:
In future versions of vStudio we wil have scripts which builds simple 
database
applications using vStudio. If we will store these logic into the 
database itself
we will soon get in trouble in case of updates...
Having the "logic" (Scripts and preferences) in a seperate file the 
user only have to replace
this .gui file...


-- 
Best regards,
Jochen Peters
PIIT GmbH

------------------------------------
http://www.valentina-db.de