GnuCash Daily Source Diff

[Dave Peticolas]

--=-IFKOGXO0q2WS3WUgGiSA
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Thu, 2001-10-04 at 07:39, Linas Vepstas wrote:
> On Thu, Oct 04, 2001 at 08:05:21AM -0500, Dave Peticolas was heard to rem=
ark:
> > -  account =3D xaccMallocAccount ();
> > +  account =3D xaccMallocAccount (session);
>=20
> I'm trying to guess why you'd need a session in 'create' ... but can't.
>=20
> A lone, disconnected transaction (or account) is kind of 'meaningless';=20
> it only comes to life when its manipulated  between a BeginEdit..Commit=20
> pair.  At that point, you would know what the session is ...

In order to allow multiple, independent sessions to be open at
the same time, we need to remove the remaining global variable
in the engine, the entity table. As long as the entity table
is global, you can't have multiple sessions opening the same
file, otherwise the second session will overwrite all the
entries in the global table from the first session.

Thus, I am moving the entity table into the session. The current
engine semantics for account/transaction/split creation is that
these structures create their GUID's immediately and insert themselves
into the table, so that they are accessible through their GUIDs=20
throughout their lifetime. If we give up those semantics, then
we probably can ditch most of the extra session arguments.

There is some existing code depends on being able to get to
transactions through GUIDs before they are 'connected'
to a session through account pointers.


> I am somewhat concerned that assigning a transaction to some session=20
> for the entirety of its life will prevent the ablity to copy
> transactions from one session to another.   This is how I get data into
> the sql db: open a file, read, (close the file, close the session),
> open the sql session, write. =20

What you want to do is move them right? I don't think you would want
two sessions to have common transactions, i.e., transactions with the
same (Transaction * pointer), not just the same GUID. That wouldn't
make any sense. If you are copying transactions then you would want to
clone them. If you want to do a 'save as', where you discard the old
session, then you could just move the book and the entity table from
the old session to the new one. I intend to make a session
function to support that.


> The alternative would be to 'clone' all accounts/transactions into a=20
> new session, but this would be quite inefficieint.  And seemingly
> pointless, since at the momemnt, with global sessions, you can't have
> more than one 'current' session at a time.

The GUI certainly assumes a single, primary session, and I don't
intend to change that anytime soon. I am trying to get the engine
to allow operation with multiple sessions. This make it a lot easier
to test the sql backend and it also allows the rpc server to work as
intended. Weren't you just calling for the separation of Books and
Sessions so that there was no longer a 1-to-1 mapping between them?
What do you see as the role of sessions?


> Or is it that you are trying to have two current sessions at the same
> time?   It always seemed that having one current session at a time was
> enough. And if it wasn't, you could always get/set the current session=20
> to use teh one that you want (since your single-threaded anyway).
> And if you eeded multiple threads, you'd use pthread_get_specific(),
> so you could have an independent session per thread.

As I say, I maintain that right now the engine can't support multiple
sessions unless the user makes sure to never have two sessions opening
the same underlying data file, or two files with common GUIDs, which
you could get from, say, opening a .xac backup file and the main file.

dave


--=-IFKOGXO0q2WS3WUgGiSA
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQA7vNdh5effKKCmfpIRAl37AKCVr11JnQSAcZ4SbzENzIB6PgEjNwCg539I
k20xaE2UTfkEnnUXvc1+qLA=
=KmuO
-----END PGP SIGNATURE-----

--=-IFKOGXO0q2WS3WUgGiSA--