On Tue, 09 Nov 1999 21:31:38 CST, the world broke into rejoicing as
[EMAIL PROTECTED] said:
> > > -) fast key lookup
> > > -) relational model (vrs hierarchical for a filesystem)
> > > -) complex data joins
>
> Those are SQL pluses. SQL minuses are that you can't/wouldn't want to
> run it over the open internet, not even with SSL in place, say the
> way that CVS is internet-sort-of-safe.
>
> In particular, I occasionally daydream of gnucash as being a
> gui-front-end to some remotely located server. Using SQL as the wire
> protocol for this would be a mistake for security reasons, compatibility
> reasons, portability reasons. But if we don't use SQL as the wire
> protocol, what do we use? XML? IIOP-RMI (corba==java rmi)? roll-your-own?
> Any of these require you to define either an API or a data model of some
> sort.
I'd think it a Whole Lot More Sensible to pick CORBA than any of the
other options; RMI ties you forcibly to Java, whilst XML is "merely a
data file format," requiring some transport to go-on-top-of.
I agree that SQL is a big mistake; it only supports connecting to
the database, whereas what you actually *want* to do is to do more
transaction-oriented stuff.
> This is why it seemed wise to define a clear separation between
> gui and engine. The separation allows gui end engine development to
> prioceed separately, and allows you to not tangle up code from disparate
> subsystems. To say that the 'gnucash engine data model is poor' is a
> misleading statement: the limitation is on the part of the GUI, which
> does not know how to handle anything more sophisticated than what the
> engine provides. I'm confident that adding engine function and expanding
> its data model is a far simpler task than coming up with the GUI to deal
> with that.
>
> > (set! foo (somedb:create-database "/home/rlb/personal-accounts.gnc"))
> > (somedb:create-table foo ...)
> > (somedb:create-table foo ...)
> > (somedb:close-database foo)
>
> I do not mean to discourage an SQL back end; I think this would be great.
> But I think it would be a fundamental mistake to allow either the GUI
> or the scheme to manipulate the SQL directly as shown above. I'm afraid
> of stating this too strongly, because I think it'll raise hackles, but I
> think there's real merit to modularity, objects, componenets, reusable
> pieces. It would be a major mistake, a step back to merge sql and
> scheme/gui together directly without abstraction in between.
I would rather like to see this look more like the following:
a) For raw file access:
(set! foo (somedb:connect-db 'RAWFILE
(build-path (getenv "HOME") "myaccts")))
;;; which creates the directory /home/cbbrowne/myaccts, if it don't exist...
b) To access a PostgreSQL db:
(set! foo (somedb:connect-db 'SQL
'(PostgreSQL (getenv "HOST") (getenv (string-append "LOGNAME"
"-myaccts"))))
c) To access a DB via ODBC:
(set! foo (somedb:connect-db 'ODBC
'((getenv "HOST") 2140 ; port number
'("cbbrowne" "my-password-is-wimpy"))))
Functions like:
(create-table foo tablename list-of-table-properties)
(map-query-records foo tablename list-of-desired-properties
function-to-apply-to-each-record)
(insert-record foo tablename list-of-record-fields)
could have various methods associated with them that would vary based
on which access method is in use for "foo".
This is quite essentially object-oriented; in C, this probably amounts
to having the "database accessor" foo be a structure not unlike a file
access handle, only with a rather different set of values in it, perhaps
like:
enum db_type_enumeration { odbc, rawfile, postgresql, mysql }
struct db_accessor {
db_type_enumeration db_type;
union db_accessors {
struct odbc_accessors;
struct rawfile_accessors;
struct pgsql_accessors;
struct mysql_accessors;
}
} foo;
And
struct odbc_accessors {
/* Bunch of pointers to access functions for ODBC methods */
}
struct rawfile_accessors {
/* Bunch of pointers to access functions for raw file methods */
}
...
There is *no* need for the GUI to have any SQL access code in it;
it should be hitting on engine code.
--
"I have seen the future, and it does not work."
[EMAIL PROTECTED] <http://www.hex.net/~cbbrowne/lsf.html>
--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]
