Setting up gnucash to use postgesql back end - close but no cigar ...

[John Ralls]

> On Mar 11, 2015, at 10:22 AM, Jan Steinman <Jan at ecoreality.org> wrote:
> 
> On 2015-03-10, at 17:08, John Ralls wrote:
> 
>> 
>>> On Mar 11, 2015, at 2:04 AM, Jan Steinman <Jan at ecoreality.org> wrote:
>>> 
>>>> From: John Ralls <jralls at ceridwen.us>
>>>> 
>>>> ... once we switch to using SQL as the internal data representation...
>>> 
>>> be_still(heart);
>>> 
>>> I *really* want an inter-operable SQL back-end. I can almost taste it.
>>> 
>>> I looked at the current data model (in MySQL), and it looks like... it's not really a data model. More like a general data dump (slots table). Perhaps I could be of assistance.
>> 
>> Hmm. Interoperable with what?
>> 
>> Yes, it's true that the current schema is just a persistence of GnuCash's internal representation. That's pretty standard for business applications if my reading of Fowler's "Patterns of Enterprise Application Architecture" is correct. In any case it's not likely to change: All of the business logic is likely to stay in GnuCash rather than move to the database.
> 
> The purpose of a data model is to *divorce* data representation and its manipulation from the user interface. It increases cohesion and reduces coupling.
> 
> I see Fowler (et. al.) seem to be heavily influenced by Reenskaug, Goldberg, Krasner, et. al. in this regard -- they even have a chapter on "Model, View, Controller," which was originally a Smalltalk concept, invented by Reenskaug.
> 
> The purpose behind MVC is to focus on getting the data model right, so that multiple Views (which is NOT the same as a "view" in SQL) could present it in different ways, and different Controllers could manipulate it in different ways.
> 
> If "the business logic is likely to stay in GnuCash," then how the heck will you ever get it to be multi-user? Or is that not an important goal?
> 
> If I may, I'd suggest that the data model should be capable of being driven independently of the View and Controller. That's been my "gold standard" during 20 years of object-relational consulting practice. But few of my clients ever got completely there... :-)

OK. Yes, the model is the abstract design of the classes and their interactions. The data model is the part of the model dealing with persisting objects. The model itself doesn't exist in code, whether it's database code or application code, because it's abstract. It's expressed in code. There is some documentation of the data model in src/docs, though we've not been very good about maintaining it since it was written ~12 years ago, so it's a bit out of date.

Most object-oriented patterns originated in SmallTalk. The standard intermediate reference is Gamma et al., "Design Patterns", often referred to as "Gang of Four" or "GoF". It's also the parent of all software design books named "Patterns...".

Enough CS history, and enough theory.

The expression of the model is in GnuCash code, and there it is likely to stay. Multi-user access to GnuCash databases will be accomplished by multiple instances of GnuCash operating on the same database, using the standard database synchronization functions. We'll probably also designate foreign keys and some enforcement of referential integrity to the extent we can do so purely in standard SQL. Being able to work on top of different database engines (SQLite3, MySql, and Postgresql) is an important constraint: We want those users who need multiuser access to be able to set up on a server, but we want the vast majority of users who don't need multiuser to be able to just save to a file.

Yes, of course the Model should be separate from the View and Controller parts of the application. It mostly is in GnuCash; you'll find the core of it in src/engine and src/libqof/qof. Unfortunately because of the way GnuCash migrated from Scheme to C and some poor implementation choices over the years has led to leakage of Model code into other parts of the application. One of our goals over the next several years is to clean that up, in large part to make it easier to migrate the application to other GUI platforms (Android and iOS in particular, though no doubt something else will have come along by the time we're done).

You complained in your opener about the slots table. No argument that that's a wart. It reflects the Key-Value-Parameter (KVP) structure of the XML schema that was created, and is still used, to allow optional features to be added while allowing older versions of the program to continue to work with the main part of the data. It's been rather badly overused and will cause performance issues once we stop loading everything into memory at startup, but for peripheral bits of data there's nothing inherently wrong with it.

That's the direction I'm leading us. Where would you go?

You never answered the question about what you mean by "interoperable".

Regards,
John Ralls