> > -- be able to query ANY parameters/options that are settable by us or
>> by kernel, including things like file mode, file block size, mac file
>> type/create, file extensions.
>
>You mean by SQL?
>No promise. WE have start add SQL command SET PROPERTY, GET PROPERTY,
>But on the hold now.
Direct API will do. Actually non-SQL way is better for now. Those
things are needed only under special circumstances.
> > -- be able to store single global/persistent values easily (using
>> system tables instead of having to maintain my own bo)
>
>Close to SET PROPERTY.
Property of what? I must have missed this topic somehow. But if they
allow me to maintain single global values, I am game. But make them
available in direct API as well.
> > -- add SQLSelectField and SQLSelectGlobal
>
>?
Search list archive for this thread.
> > -- option to have automatic time stamping of all or specific fields
>> in a baseobject (updated only when content changes)
>
>Yes, we have add DB.Clocks(), and TIMESTAMP field.
Is the TIMESTAMP an internal field (handled automatically by kernel)
or it is a field for us to use explicitely? Ideally, a field would
have a property "timestamp" settable through Field_SetFlag() and then
we have a call Field_GetTimestamp() to find the current value. It
should also be properly handled through SQL, so we can easily find
records with fields that were modified after specific timestamp.
> > -- does valentina automatically zeros out space that becomes empty
>> when existing data is encrypted? if not it should. And add an option
>> for doing this upon any record deletion (a new call or an option for
>> delete/all/Record/s)
>
>Yes, is added new flag db.EraseOnDelete.
>For non encrypted also
For non-encrypted should be optional for performance reasons.
> > -- built in options to compress large data upon storage and auto
>> decompress upon recall (choice of compression)
>
>Mmm, this exists now -- ZIP compression for BLOBs.
Hmm, may be it exists but there is no mention of it in any of the
docs I have, so I have no clue how to use it.
I'd like this to be simply a field attribute like with indexing or
unique -- I just call Field_SetFlag() to make field zip-compressed.
By BLOBs, do you mean BLOB fields or all BLOB-type fields (that is
BLOB, TEXT, PICT)?
> > -- simplify opening/creating encrypted database: New +
>> Set(Structure)Encryption + Open --> CreateEncrypted and
>> Set(Structure)Encryption + Open --> OpenEncrypted with Open returning
>> an error dbEncrypted when trying to open an encrypted db. Also
>> IsStructureEncrypted(fpath), IsDatabaseEncrypted(fpath) to check what
>> kind of db we have (this was discussed on the list last year)
>
>Let's discuss this in separate thread.
>And I did agree in the past with changes?
>Just not sure it is possible simplify something.
Search list archive for past discussions. No, you did not actually
agree to do this. But yes, I still find these steps non-intuitive and
more complicated than needed, particularly for programs that allow
our users to have either encrypted or unencrypted databases. Now it
is an opportunity to clean this up.
Your current approach may be logical in VSDK but not in higher
languages. I don't care what you do internally -- you can just call
the current functions as they are.
> > -- implement auto timeout of cursors
>
>What you mean?
See page 18 of vxcmd manual from December. Although to be truly
useful, this should be a property of a cursor not a database (a
parameter on SQL call that sets max age in seconds, 0 meaning no
expire).
> > -- option to open databases in read-only mode (as parameter to open
>> or separate call) regardless whether it is on read-only or read-write
>> medium
>
>Aha, as flag on open....
>I afraid not works.
>
>Assume files are not marked.
>One app open as read only. Ok.
>But other open as read/write => BIG PROBLEMS.
I am not sure problems are so big (at least in my ignorance :)
So what if the other app modifies a content of the field. The first
app will get the new content (ya, live cursor modifiable by others).
That is often desirable. If the 2nd app deletes a record, first
should get an error "recordDeleted". If 2nd app makes any structure
changes, 1st app returns "cursorNoLongerValid" error. Do I miss
anything?
But, you can (at least initially) restrict that if a db is open for
read, other apps can open it also for read only. A lock file could be
used if there is no better way. (A change file could be used to pass
level of changes from the read/write up.)
>
>> -- valentinaInit returns the size of actually allocated cache
>
>Right now.
Hmm. In vxcmd, it returns empty when successful.
>
> > -- use opportunity to clean up function/param names in BO-APIs
>
>?
For example, SetStructureEncryption()/SetEncryption() should be
really called PassStructureEncryptionKey()/PassEncryptionKey() since
that is what they do. But (cf above) encryption key should be passed
with OpenEncrypted() not as a separate call aynway.
A few other examples:
Database_Dump() could be Database_WriteDump() or Database_MakeDump()
to parallel Database_LoadDump(). May be even better to make them
Database_ExportDump() and Database_ImportDump() to parallel
Database_ExportAscii() and Database_ImportAscii(). Anything you write
out to an external file is export and anything you read from external
file is import.
Cursor_GetField() could be Cursor_GetFieldValue() to match
Cursor_GetFieldName(), Cursor_GetFieldRef() and also Field_GetValue()
-- or the latter should be Field_Get to match Cursor_GetField.
Actually, Cursor_GetFieldContent() and Field_GetContent() would be
even more appropriate.
Cursor_SetBlank() does not set the whole cursor so it should be
Cursor_BlankRecord() or Cursor_SetRecordBlank().
I realize that we got used to those names as they are but changing to
version 2 is a unique opportunity to make function names more
self-descriptive with less ambiguities. I just like them nice and
clean and logical :)
A new item:
Do you remember THINK Reference? It was basically a smart searchable
database that contained syntax of all functions from System Toolbox
and Think language reference. May be such a database convering all
your products would be useful for us and you. There would be a
standalone GUI to use it but the raw database would be also available
for integration into at least some development environments.
Robert
_______________________________________________
Valentina mailing list
Valentina AT lists D.OT macserve.net
http://lists.macserve.net/mailman/listinfo/valentina
©2004 Robert Brenstein |
