2018-11-29 GnuCash IRC logs

00:46:45 *** blobdata has joined #gnucash
00:47:49 <blobdata> hi , i just have a technical question : what are the most basic privileges required by the mysql backend to access database in gnucash(read only)
00:48:59 *** marusich has joined #gnucash
00:49:49 <blobdata> hi
01:07:17 *** Mechtilde has joined #gnucash
01:08:32 *** fell has quit IRC
01:10:22 *** fell has joined #gnucash
01:43:43 *** bertbob has quit IRC
01:52:32 *** nimish has joined #gnucash
01:55:45 *** Mechtilde has quit IRC
01:57:17 *** gour has joined #gnucash
02:01:49 *** bertbob has joined #gnucash
02:04:58 *** bertbob has quit IRC
02:10:28 *** chris has quit IRC
02:12:04 *** nimish has quit IRC
02:15:45 *** nimish has joined #gnucash
02:16:44 *** jotrago has quit IRC
02:20:34 *** bertbob has joined #gnucash
02:25:09 *** fabior has joined #gnucash
02:29:15 *** fabior has quit IRC
02:29:33 *** gjanssens has joined #gnucash
02:29:33 *** ChanServ sets mode: +o gjanssens
02:40:50 *** marusich has quit IRC
02:41:32 <gjanssens> .
02:49:01 *** fabior has joined #gnucash
04:08:41 *** kapil___ has joined #gnucash
04:11:17 <kapil___> jralls: I am building from github repository master branch
04:12:42 <jralls> kapl___: Gotta run, back in an hour or so. It looks like cmake couldn't figure out that yuo're building from git and is looking for the swig files.
04:17:46 <kapil___> Ok I wait
04:26:20 *** Aussie_matt has quit IRC
04:37:58 *** Mechtilde has joined #gnucash
04:38:48 *** manjaro-user has joined #gnucash
04:43:03 <gour> morning
04:44:49 <gour> running GC under manjaro - when i launched it from gui, it uses decimal point for amounts, but when launched from the terminal it uses decimal comma which is according to my preferred currency (and locale settings), but wonder why it does not use decimal comma when launched from gui since for HRK currency, that's default behaviour?
04:48:02 <gour> i've changed my LANG globally and set Croatia for formats (Region under GNOME), so that will probably help, but can't logout now since i'm still restoring my home-data from the backup
04:48:12 *** Rachael has joined #gnucash
05:10:56 *** manjaro-user has quit IRC
05:25:35 *** manjaro-user has joined #gnucash
05:58:34 <gjanssens> kapil___: did you start from a git clone or from a tarball downloaded from git ?
05:58:47 <gjanssens> The latter won't work unless it's one of our formal release tarballs
05:59:32 <gjanssens> gour: that should do it
06:01:14 <jralls> kapil___: OK, back. The git detection works by finding .git/ in the source directory. Did you do a git clone to get the sources?
06:01:46 <gjanssens> Hi jralls
06:02:02 <gjanssens> That's what I asked 3 minutes ago as well :)
06:02:13 <gjanssens> How's your travel going btw ?
06:02:35 *** fabior has quit IRC
06:03:15 <jralls> gjanssens: Reasonably OK. I'm more than ready to go home, but Ellie still has one more shrine on her list.
06:03:29 <gjanssens> Ok :)
06:07:13 <jralls> In the meantime I got the first of my Gtk-Quartz merge requests up and I've run clang static analyze on GnuCash. I'm wading through the complaints.
06:08:04 <gjanssens> Cool
06:08:29 <gjanssens> I recently discovered clang-tidy. Is that the same thing ?
06:09:07 <jralls> No, clang-tidy is a source formatter like the artistic-style that we've used periodically.
06:09:41 <gjanssens> Hmm, then I'm using the wrong name, because the tool I ran did static analysis as well
06:10:11 <gjanssens> Can't remember the name right now, I'm still working on things completely outside of gnucash currently
06:10:33 <jralls> I'm actually cheating and using Xcode to run the static analyzer, but from the command line one would use `scan-build` in place of `clang`.
06:12:56 <gjanssens> It was clang-tidy after all: https://www.kdab.com/clang-tidy-part-1-modernize-source-code-using-c11c14/
06:13:33 <kapil___> gjanssens: i start by tarball downloaded from git.
06:13:54 <gjanssens> kapil___: right. That won't work :(
06:14:07 <gjanssens> You'll have to really clone the repository instead
06:14:21 *** nimish has quit IRC
06:14:22 <kapil___> thanks i will try to clone repository
06:14:45 <jralls> Or use a release tarball. ATM you don't want to build master anyway, all of the recent work has been on maint.
06:14:49 *** nimish has joined #gnucash
06:14:56 <gjanssens> Good point
06:16:21 <jralls> gjanssens: Re clang-tidy, that's a bit different. It's doing refactors. The static analyzer tests different code paths and finds mistakes like double-frees, leaks, using uninitialized variables, and so on.
06:16:45 <jralls> Refactors are good too, but best applied after cleaning up all of the boo-boos.
06:17:26 <gjanssens> Right, that makes sense
06:18:10 <jralls> Changing subjects a bit, I've been mulling over what should be my next priority on master. Right now I'm leaning towards changing the XML backend to create an in-memory SQL DB. After that we can get rid of QofQuery and use SQL, which should be much faster and vastly more flexible.
06:18:37 <jralls> And also QofCollection, I think.
06:18:41 <gjanssens> Sounds like a good approach
06:18:52 <gjanssens> What would be the other options for next priority ?
06:19:44 <kapil___> jralls: thanks i will clone maint
06:20:19 <jralls> Converting engine classes to C++ with proper constructors so that the backends can atomically instantiate objects instead of creating an empty one and setting its properties one by one.
06:21:38 <jralls> But I think getting the query part of QOF out of the way will simplify that a lot.
06:21:53 <gjanssens> Hmm, tough choice, but I tend to agree with you.
06:23:06 <gjanssens> How do you envision an 'in-memory' SQL db ?
06:23:15 <jralls> A nice aspect of querying SQL is that we can do it for lots of things and only instantiate objects for editing.
06:23:18 <gjanssens> That's a new concept in gnucash code AFAIU
06:24:13 <jralls> Yeah, it is, but it's essential to multiple simultaneous use.
06:24:17 <gjanssens> I'm all for sql querying
06:24:35 *** Mechtilde has quit IRC
06:24:49 <jralls> SQLite3 provides an in-memory DB option.
06:24:57 <gjanssens> Ah, that's good
06:25:37 <gjanssens> I suppose you mean going sql all the way is essential for multiple simulatneous use, so msyql or postgresql would be fine, but xml isn't ?
06:26:09 <gjanssens> And here's you're talking specifically about the xml part
06:26:52 <gjanssens> that you want to replace with an in-memory sql db
06:27:22 <jralls> Hmm. No, it's more that loading everything into memory and only writing afterwards is incompatible with concurrent use.
06:28:14 *** tienne has joined #gnucash
06:28:18 <gjanssens> I do get that. But it seems to me there are two steps right ?
06:29:17 <jralls> What two steps are you thinking of?
06:29:18 <gjanssens> 1. make xml load into an sql db (in memory) so there's only one backend interface left from the engine's point of view
06:30:05 <gjanssens> 2. rework the sql backends and engine to use sql queries for everything, and switch to the sql for lots and instantiation for editing
06:30:53 <jralls> Oh, I see where you're going: With XML<->in-memory SQLite DB there's still no IPC. That's absolutely correct.
06:31:23 <gjanssens> And looking further it's probably the editing part that makes it problematic for multiple concurrent use
06:31:42 <jralls> Even with SQLite3 on a shared FS the latency needs to be low enough for the IPC to work without racing. Dropbox won't work.
06:31:53 <gjanssens> As we can't keep a lock on the db while the user is editing
06:32:36 <gjanssens> The more general issue here is that we'll have to think about collisions and how to handle those
06:32:54 *** Mechtilde has joined #gnucash
06:33:39 <jralls> The DBs all provide concurrency support, though SQLite3 does it a bit differently from the server-based ones.
06:33:59 <gjanssens> Of course.
06:34:32 <gjanssens> What I'm thinking about is suppose 2 users are looking at the same account register in the same db, but via different gnucash instances
06:35:16 <gjanssens> If one user changes say a split, the other won't necessarily notice and may make a conflicting change a bit later
06:35:44 <gjanssens> The db will happily accept both changes as they didn't happen exactly at the same time (and even then it would simply queue one after the other)
06:36:03 <gjanssens> But user A may be assuming wrong information after the change of user B got in
06:37:01 <gjanssens> I imagine some kind of query-verify-write cycle for updates
06:37:35 *** Jimraehl1 has joined #gnucash
06:37:36 <jralls> When user1 opens the txn for editing GnuCash takes out a lock and user2 can't edit it. When user1 commits her edit it fires a trigger in the DB that tells User2's instance of GnuCash to reread the row.
06:37:38 <gjanssens> Query the current value, if it is still the same as when we last checked, simply write, otherwise inform the user of a conflict
06:38:06 *** Jimraehl1 has left #gnucash
06:38:22 <gjanssens> Ok, if that trigger mechanism exists in all db's we support that's the easiest solution indeed.
06:38:37 <jralls> Remember, the DB guys have been thinking hard about all of this for 40 years. No need for us to invent any wheels.
06:38:46 <gjanssens> Heh, I hope so!
06:39:18 <gjanssens> Does libdbi expose such triggers ?
06:39:31 <gjanssens> Or do you intend to switch to odb in the rewrite ?
06:39:31 <kapil___> thanks git clone mint branch worked successfully
06:39:41 <gjanssens> kapil___: \o/
06:39:43 <jralls> kapil___: Excellent.
06:40:57 <jralls> I don't think libdbi supports either triggers or stored procedures. Neither are in the SQL standard but both are ubiquitous.
06:43:40 <jralls> ODB does, though it might be a bit heavyweight for our needs. It might be easier to just write separate shims for each DB backend. That's far enough out that I'm not going to worry about it right now as what's available is likely to change by the time we're ready.
06:44:00 <gjanssens> Ok and true
06:44:10 *** Mechtilde has quit IRC
06:45:33 *** Mechtilde has joined #gnucash
06:47:02 <jralls> The chain as I see it is SQL replaces QOF->C++ engine and atomic object construction->on-demand object construction->cocurrency.
06:47:35 <gjanssens> Good
06:47:36 <jralls> A long and winding road, like the old song.
06:47:42 <gjanssens> :)
06:48:14 <gjanssens> So true concurrency will still be a while, but replacing qof with sql is the next big step in the right direction
06:48:29 <gjanssens> Looks good to me.
06:48:36 <jralls> Yeah. That should be a big help for chris's reports.
06:48:47 <gjanssens> Indeed, that as well
06:49:51 <jralls> Meanwhile other work that could happen concurrently includes MVC separation and de-schemifying things like options.
06:50:43 <jralls> And doing something about reg2.
06:51:50 *** Mechtilde has quit IRC
06:53:40 <kapil___> I want to learn code. from where should i start
06:54:46 *** chris has joined #gnucash
06:55:23 *** Mechtilde has joined #gnucash
06:55:47 <jralls> kapil___: Depends. Where are you now? Are you fluent in C, C++, and/or Scheme? Familiar with Gnome development?
06:55:47 <kapil___> i successfully compiled gnucash, I want to learn how it works. how the project is organised?
06:56:43 <kapil___> no i tried Qt some years ago, but was not successful. recently started again learning c, c++ from a week
06:57:50 <jralls> Until you're fluent in the language you're not going to make much progress with GnuCash. It's a large and unfortunately overly complicated program.
06:58:42 <kapil___> thanks, do i have to learn only c for gnucash?
06:59:35 <jralls> You can look at the Doxygen documentation at https://code.gnucash.org/docs/MAINT. There's lots of information on the Wiki, so browse around that.
06:59:58 <kapil___> thanks a lot.
07:01:14 <jralls> Depends on what you want to do. Most of it is in C. The reports system is in Scheme and there are bits of Scheme in some other places, left over from when the whole thing was Scheme. We're on a many-year mission to convert everything under libgnucash to C++.
07:02:02 <jralls> Then there's the GUI, which is written around Gtk. It's based on a weird object-oriented library written in C called GObject.
07:02:25 <gjanssens> jralls: yeah, the others are all things I had on my tentative list
07:02:38 <kapil___> jralls: oh thanks
07:03:04 <gjanssens> reg2 is pretty high on my agenda as is de-schemefying all of libgnucash
07:03:24 <gjanssens> options are at the lowest level in there so they should be a good first candidate
07:03:38 <gjanssens> Also the biggest part :)
07:08:25 <chris> I should be able to generate some options tests
07:08:49 <gjanssens> chris: good
07:09:05 <jralls> Maybe add to that squashing most of libgnucash into, well, libgnucash.so as a shared library instead of a loadable module. I think that we could do some more finer-grained source reorganization as well.
07:09:29 <gjanssens> Hmm, yep, got that on my list as well for some time...
07:09:46 <gjanssens> Getting rid of scheme in libgnucash is probably a prerequisite though
07:10:37 <jralls> chris: Good indeed, the catch being figuring out where the line between C/C++ and Scheme goes. Until you're ready to dive into C ( ;-) ) your tests will only be from the Scheme side.
07:10:43 *** gour has quit IRC
07:11:51 <chris> jralls of course, I expect all options to run unchanged from scheme.
07:11:53 <jralls> chris: The de-schemification gjanssens is talking about is that the options system goes c->scheme->c and then for reports back to scheme again. It's a horrid mess.
07:12:32 *** gour has joined #gnucash
07:14:12 <gjanssens> chris: I can't tell yet whether the options interface visible to scheme can remain unchanged
07:14:30 <gjanssens> But in both cases it's good to have option tests
07:14:40 <gjanssens> They may require updating along the way
07:14:40 <kapil___> jralls: can i ask, why you planning to move to c++, c is easier.
07:14:55 <gjanssens> kapil___: that's an ongoing project
07:15:18 <gjanssens> It make take years before it's complete, but some parts are C++ already
07:15:41 <gjanssens> And frankly whether c is really easier is debatable
07:16:02 <kapil___> isnt going to make it in c++, make it more complex?
07:16:07 <chris> well i'll leave this mess to you guys to detangle...
07:17:03 <chris> kapil__ 'easier' is always subjective. I find scheme/guile easier, to the detriment (& benefit) of everyone here
07:17:08 <gjanssens> Not necessarily, and modern c++ (c++11 and more recent) allows to avoid plenty of memory allocation headaches
07:17:24 <jralls> kapil___ Modern C++, especially C++11 and later, is a very different language from the C++99 that Qt uses.
07:17:47 <jralls> It's far more powerful and far safer.
07:18:07 <kapil___> jralls: oh thanks a lot.
07:18:24 <jralls> Plus, you haven't tried GObject yet. It's a real PITA.
07:18:59 <kapil___> thanks, i will try it.
07:19:14 <jralls> I wouldn't unless you have to...
07:19:49 <jralls> It occurs to me that you might not know that PITA is "pain in the arse".
07:20:04 <kapil___> oh thanks,
07:20:23 <kapil___> then i will try to avoid it
07:22:27 <gjanssens> kapil___: :) which means you won't be able to contribute to current gnucash as it's mostly based on GObject :(
07:23:23 <gjanssens> A large part of our move to C++ involves conversion from GObject based data structures to C++ classes
07:23:49 <gjanssens> So if you want to help out (which you're most welcome), you can't avoid it yet I'm afraid...
07:24:13 <gjanssens> You will see a mix of GObject and C++ until we're done
07:37:20 <chris> gjanssens: I'll design test-options to freeze the current implementation, if you wish to change afterwards, no big deal...
07:41:04 <kapil___> gjanssens: oh thanks I will try the new c++ classes for gtk.
07:44:42 *** nimish has quit IRC
07:45:11 *** nimish has joined #gnucash
07:46:44 *** gour_ has joined #gnucash
07:48:54 *** gour has quit IRC
07:54:13 *** gour_ is now known as gour
08:00:54 <gjanssens> chris: very good
08:01:35 <gjanssens> kapil___: gtk has c++ wrappers in the gtkmm library
08:02:03 <gjanssens> This is currently not used in gnucash, though we have considered it in the recent past
08:02:21 <gjanssens> So for now there are no c++ classes for gtk in gnucash
08:03:07 * gjanssens feels a bit awkward clarifying the current state of the gnucash code like this :(
08:03:48 <gjanssens> The first potential candidate to use gtkmm would be the csv import assistants (transaction and price)
08:04:04 <gjanssens> Both are completely c++ except for the gui
08:04:27 <gjanssens> That would mean changes to our build system to use gtkmm in addition to gtk+
08:05:03 <gjanssens> That's a lot of moving parts for someone just starting to learn how to code
08:05:33 <gjanssens> So I would propose instead you start with smaller bugfixes to learn more of how the code is organized
08:05:56 <gjanssens> There are plenty of bugs to investigate in our bugzilla instance: https://bugs.gnucash.org
08:06:23 <gjanssens> Or you can scratch your own itches of course, but as said in many cases this is challenging as a starting project
08:07:47 *** jwhitmore has joined #gnucash
08:09:58 *** boldstripe has joined #gnucash
08:11:05 *** jwhitmore has quit IRC
08:14:38 *** jwhitmore has joined #gnucash
08:17:06 *** tienne has quit IRC
08:17:59 *** oozer has joined #gnucash
08:19:10 *** tienne has joined #gnucash
08:20:14 <kapil___> Thanks for help. I will try to make pull requests if I can.
08:22:57 <gjanssens> Great!
08:23:23 <gjanssens> fell, jralls, Mechtilde: I ran into this article today https://www.berrange.com/posts/2018/11/29/improved-translation-po-file-handling-by-ditching-gettext-autotools-integration/
08:23:44 <gjanssens> It does contain some interesting considerations on working with po files in a git environment
08:24:48 <gjanssens> libvirt manages translations via Zanata, so the article is focused around that, but I think several parts are generic and can be beneficial for gnucash as well.
08:25:02 *** nimish has quit IRC
08:25:10 <gjanssens> Regardless of which tool is eventually used for doing the actual translation work.
08:25:40 *** nimish has joined #gnucash
08:29:26 <jralls> gjanssens: Well, we already don't use the autotools integration since we don't use autotools anymore. ;-)
08:30:51 <jralls> And our translators, at least at present, *do* use the po files directly so maybe the citations to msgid location in code is still needed.
08:32:30 <jralls> In general we don't change the po files unless a translator updates something so there isn't really much git churn.
08:34:42 <jralls> On the other hand a translator would usually msgmerge the po against the latest pot before doing an update and that would generate a lot of noise in the change, especially if he updated only a few msgstrs. Maybe stripping the citations from the po before committing would be a reasonable thing to do.
08:35:07 <jralls> Since msgmerging with the potfile will put them back.
08:35:29 *** nimish has quit IRC
08:36:00 *** nimish has joined #gnucash
08:45:52 *** nimish has quit IRC
08:46:20 *** nimish has joined #gnucash
08:46:52 *** manjaro-user has quit IRC
08:47:22 *** manjaro-user has joined #gnucash
08:47:46 *** User has joined #gnucash
08:48:16 *** Mechtilde has quit IRC
08:50:17 <warlord> blobdata: I think you'll have to test that out yourself; we assume full read/write capabilities.
09:03:34 <gjanssens> jralls: that was indeed the part I thought interesting.
09:04:19 <gjanssens> I also like the idea of not committing the pot file as it's autogenerated anyway
09:05:24 <gjanssens> So we could go the same route of adding build rules to generate a full po file based on a stripped down version where the stripped down version is the one we track in git
09:05:35 *** User has quit IRC
09:06:04 <gjanssens> Having the rule to generate a full po file can help translators that do work directly on po files as it would give them a po file with code locations that are actual
09:09:28 *** manjaro-user has quit IRC
09:17:52 *** manjaro-user has joined #gnucash
09:19:03 <warlord> gjanssens: except that requires translators actually be able to build gnucash (as opposed to just building the translation file for testing)
09:19:20 <warlord> IIRC, historically that had sometimes been a problem
09:20:16 *** fabior has joined #gnucash
09:21:17 <gjanssens> warlord: I don't think they'd need to know how to build gnucash, only how to build the po file
09:21:38 <gjanssens> But yes, those have a common set of hurdles to overcome
09:22:01 <gjanssens> I'm still considering this as intermediate stages to some kind of high level front-end
09:22:17 <gjanssens> Zanata is one such front end, as is Pootle or Weblate
09:23:02 <gjanssens> Or the Translation project for that matter, but I think their infrastructure got stuck on last decade's norms
09:24:41 <gjanssens> I'm not promoting any of the alternatives (yet), but they do offer a better translator experience in general and require less technical knowledge from potential contributors
09:25:13 <gjanssens> No doubt they have their own issues which we will only discover if we actually test them.
09:26:12 *** nimish has quit IRC
09:26:43 <warlord> Must we choose one?
09:26:43 *** nimish has joined #gnucash
09:28:42 <gjanssens> Probably to avoid contribution conflicts
09:29:05 <gjanssens> What if one contributor starts contributing via Zanata and another via Weblate for the same language ?
09:29:12 <gjanssens> Which translations to accept ?
09:30:11 <gjanssens> Currently the situation is either TP or direct po file PR's
09:30:40 <warlord> I think each language could choose a platform.
09:30:43 <gjanssens> And we ask contributors to contact the last known translator
09:31:17 <gjanssens> But things like weblate, pootle and zanata are much more friendly to drive-by translations
09:31:51 <gjanssens> For those cases we'd be usually too late to direct the contributor to the proper platform for their language
09:32:44 <gjanssens> Unless we can configure on each platform which languages are allowed. I doubt we can
09:33:40 <gjanssens> See, I think we should not compare these webbased services with tools like PoEdit or virtaal
09:33:56 <gjanssens> They are collaboration environments for translation, not just a translation tool
09:34:44 <gjanssens> So more like github and gitlab are for code
09:35:06 <gjanssens> At least that's my high level view.
09:35:32 <warlord> Hmmm
09:35:34 <warlord> Okay.
09:35:35 <gjanssens> All can change after we run more concrete experiments
09:35:55 <gjanssens> At some point. Eventually. :)
09:36:03 *** storyjesse has quit IRC
09:56:24 *** Mechtilde has joined #gnucash
10:04:54 *** kael has joined #gnucash
10:12:31 *** manjaro-user has quit IRC
10:18:18 *** kael has quit IRC
10:26:35 *** nimish has quit IRC
10:27:17 *** nimish has joined #gnucash
10:27:36 *** manjaro-user has joined #gnucash
10:29:03 *** boldstripe has quit IRC
10:38:28 *** User has joined #gnucash
10:43:34 *** User has quit IRC
10:54:14 *** kael has joined #gnucash
10:59:45 *** manjaro-user has quit IRC
11:12:02 *** nimish has quit IRC
11:12:32 *** nimish has joined #gnucash
11:36:51 *** jwhitmore has quit IRC
11:53:50 *** badger92 has quit IRC
11:54:22 *** badger92 has joined #gnucash
12:07:23 *** nimish has quit IRC
12:07:51 *** nimish has joined #gnucash
12:24:26 *** Guest1725 has joined #gnucash
12:37:44 *** nimish has quit IRC
12:38:14 *** nimish has joined #gnucash
12:42:26 *** White-Falcon has joined #gnucash
12:45:35 *** ArtGravity has joined #gnucash
12:50:01 *** fabior has quit IRC
12:50:18 *** fabior has joined #gnucash
13:31:16 <gnomey> i cannot edit the description of a VOID transaction
13:31:36 <gnomey> so i guess i need to unmark it void, change the description, then void again
13:31:43 <gnomey> but i don't see how to unmark it void
13:32:19 <gnomey> ah, nevermind
13:40:57 *** nimish has quit IRC
13:43:37 *** nimish has joined #gnucash
13:45:32 <blobdata> just so you know SQL db with multiple users usually works trough transac SQL basically "start" a transaction do the work verify that everything is there then "commit" the transaction (SQL wise not financial wise)
13:46:56 <blobdata> this ensures that concurrent "transactions" are not processed at the same time.
13:50:40 <blobdata> @warlord thanks :-( and there i tough you could create a read-only user to use gnucash
13:50:40 <gncbot> blobdata: Error: "warlord" is not a valid command.
13:51:03 <blobdata> . @warlord thanks :-( and there i tough you could create a read-only user to use gnucash
13:55:04 <blobdata> my i suggest a small tweek for connecting to mysql : add a flag so that when 'read-only is checked' the dbi "test" only checks if Select is permitted,
14:05:47 <blobdata> found it :P : GRANT SELECT, INSERT, UPDATE, DELETE ON `immo_accounting`.`gnclock` TO 'whatever'@'%' and only SELECT on the rest of DB
14:10:04 *** jerryq has quit IRC
14:17:25 *** fekepp has quit IRC
14:17:28 *** fekepp has joined #gnucash
14:17:47 *** fabior has quit IRC
14:23:28 *** nimish has quit IRC
14:23:57 *** nimish has joined #gnucash
14:29:58 *** frakturfreak has joined #gnucash
14:32:10 *** nimish has quit IRC
14:36:36 *** Mechtilde has quit IRC
14:38:14 *** nimish has joined #gnucash
14:43:06 *** nimish has quit IRC
14:44:11 *** nimish has joined #gnucash
14:54:03 *** nimish has quit IRC
14:54:57 *** nimish has joined #gnucash
15:17:06 *** fabior has joined #gnucash
15:29:47 *** nimish has quit IRC
15:35:41 *** nimish has joined #gnucash
15:45:31 *** nimish has quit IRC
15:51:32 *** bertbob has quit IRC
15:51:48 *** fell has quit IRC
15:52:18 *** fell has joined #gnucash
15:52:44 *** gncbot sets mode: +o fell
15:55:03 *** bertbob has joined #gnucash
16:17:55 *** calvinct has joined #gnucash
16:21:17 *** gjanssens has quit IRC
16:21:39 *** User has joined #gnucash
16:25:11 <warlord> blobdata: feel free to add that to the wiki
16:25:35 <warlord> w.r.t. SQL transactions -- we understand that, but that's not the issue.
16:25:47 <warlord> Assume user A and user B both have the same account register open.
16:26:20 *** nimish has joined #gnucash
16:26:44 <warlord> User A edits a transaction and then commits it. Then user B edits the SAME transaction. The SQL transactional locks don't tell user B that user A made the change.. So user B's modifications will "overwrite" user A.
16:26:59 <warlord> The answer is notification of changes, which need to force a reload of data -- i.e. cache coherency.
16:27:39 <warlord> GnuCash needs to be told to re-fetch the data after user A makes the change and then re-display it for user B, hopefully before they try to edit the same transaction.
16:29:13 *** User has quit IRC
16:32:23 *** gour has quit IRC
16:32:32 <blobdata> hum yeah you are right about that one, its one of the shortcomings of SQL and of "non-live" data. i don't know if its actually possible from SQL to send "triggers" to client when data is changed
16:33:15 <blobdata> the other option would be to move to "live" data...
16:34:01 <blobdata> or add a "server" in between client and SQL server
16:34:33 <warlord> It is..
16:34:38 <warlord> but gnucash is not yet programmed to handle it.
16:34:45 <warlord> And each DB kinda does triggers differently.
16:35:47 <blobdata> yeah that is visibly true. you could use "lock tables" in mysql but i dont know if that is available in things like sqlite3
16:36:19 *** fell has quit IRC
16:37:53 <blobdata> but then this creates other issues ... because of the structures of the db.
16:39:12 <warlord> Yep
16:39:23 <warlord> Which is why gnucash doesn't do it, yet.
16:39:37 <warlord> (or at least one of the many reasos)
16:39:39 <warlord> reasons
16:40:24 <blobdata> for sure. well at least i figured how to have a read-only access for another user :P
16:44:59 <blobdata> on the other hand , multi-user editing done with transactions is much better than nothing at all considering you would need to edit the same transaction at the same minute or so. you could alleviate the issue also by "refreshing" the data of the opened account every 20 min.
16:46:12 *** nimish has quit IRC
16:46:41 *** nimish has joined #gnucash
16:48:01 <blobdata> its all about the question of "if i change a record someone changed already" is possible that i may loose valuable information in the minute it takes to edit the split.
16:50:02 *** Aussie_matt has joined #gnucash
16:50:04 <blobdata> and whether that "loss" is acceptable.
16:51:06 *** fell has joined #gnucash
16:51:47 *** gncbot sets mode: +o fell
16:56:32 *** nimish has quit IRC
16:57:01 *** nimish has joined #gnucash
17:01:30 *** frakturfreak has quit IRC
17:06:30 *** calvinct has quit IRC
17:11:34 <warlord> blobdata: right now there is ZERO refresh. GnuCash loads all data into RAM and deals with it all locally. It writes out changes in real-time, but it never re-reads from the DB.
17:11:52 *** nimish has quit IRC
17:12:20 *** nimish has joined #gnucash
17:17:12 *** nimish has quit IRC
17:24:39 *** jerryq has joined #gnucash
17:33:00 *** fabior has quit IRC
17:36:40 *** kali has joined #gnucash
17:38:24 *** nimish has joined #gnucash
17:40:54 *** fekepp has quit IRC
17:40:58 *** fekepp has joined #gnucash
17:43:15 *** nimish has quit IRC
17:52:33 *** fekepp has quit IRC
17:54:05 <Simon> other database access wrappers like Hibernate will version each record
17:54:10 <Simon> so you know when it's stale
18:04:06 *** rdswift has joined #gnucash
18:06:19 <jralls> blobdata: Were you able to do that from within MySQL or do we need to change GnuCash code for that?
18:06:54 <rdswift> Perhaps a dumb question, but is there any way to read security prices from a csv file (or some other format) on a Windows installation? Getting prices using the perl module is problematic.
18:08:06 *** oozer has quit IRC
18:08:18 <rdswift> I currently get them using a python script and output them to a csv to import into Quicken.
18:08:42 *** oozer has joined #gnucash
18:09:30 <jralls> rdswift: File>Import>Import Prices from CSV.
18:09:31 *** nimish has joined #gnucash
18:09:31 <rdswift> I want to ditch Quicken for something I can use with both Windows and Linux, and this is a show stopper for me.
18:10:06 <rdswift> Is that fairly new, or have I just been missing it when I went looking? ;-)
18:10:31 <jralls> It's new for 3.0, released 9 months ago.
18:11:34 <rdswift> That would be right around the last time I looked at gnucash, so I was probably not looking at that version. THANK-YOU.
18:14:24 *** nimish has quit IRC
18:14:53 *** nimish has joined #gnucash
18:19:59 *** boldstripe has joined #gnucash
18:23:04 *** kael has quit IRC
18:29:13 *** ArtGravity has quit IRC
18:29:45 *** nimish has quit IRC
18:30:13 *** nimish has joined #gnucash
18:40:06 *** nimish has quit IRC
18:40:19 <blobdata> jralls if you are talking about read-only user , no change to gnucash ... you just get a warning wen normaly gnucash would warn you about saving ... ie when exiting a split or account . everything is in the mysql db
18:41:47 <jralls> blobdata: So in this case GnuCash doesn't know that it's read-only?
18:43:15 <blobdata> its 2 fold ... on the mysql side the user only has select on the usefull data on the side of gnucash if you open the database as "read-only"(by checking the checkbox) then it will only try saving on account exit. and give you a warning
18:43:21 *** philippirrip has quit IRC
18:44:43 *** agjacome has joined #gnucash
18:45:00 <blobdata> if not checked then gnucash has no idea that it "cannot save" so it will allow edit but when it commits the data ( on split exit) then it will warn also then
18:47:44 *** p53ud0ny- has joined #gnucash
18:51:02 <blobdata> explanation: from the libdbi code for gnucash it seems that it verify's that it can add its own "lock" in the gnclock database thus needing write access to that to "validate connection" by giving access the lock is there but it cannot modify other data. still is single user but only read only this time
18:51:03 <jralls> OK. I've opened https://bugs.gnucash.org/show_bug.cgi?id=796957 to remind me to fiddle the backend so that you need only check "Read-Only".
18:52:07 <blobdata> i would say the bug is that when read only still tries to update the account on tab close
18:52:11 <jralls> Hmm, if it's read-only it shouldn't need to lock the database; in fact it offers read-only if it can't.
18:52:32 <blobdata> yeah i noticed that aswell.
18:52:45 <blobdata> maybe check for select privilege instead.
18:52:49 <blobdata> ?
18:54:44 <blobdata> just a note ( but i already added it as a feature req) the "recent files" doesn't save the "read-only" flag either... that be a nice addition so you don't need to use "open" to read-only
18:56:46 <jralls> Ah, that's you on UserVoice. Routinely opening a file as read-only isn't a use-case we've considered.
18:58:00 <jralls> I bet the complaint at the end is it trying to remove the lock rather than trying to save anything.
18:58:29 <blobdata> yeah i tought so ... we are 3 on an appartment building, i would like the others to be able to look but not modify (and possibly give an access to an accountant) thanks for the bug repport.
18:59:58 <blobdata> na its really trying to save when i close an account , i have the other message when i leave the thing opened for a few hours (mysql connection times out i guess)
19:00:55 <blobdata> starting to look a the report programming :P
19:01:08 <jralls> Do you know Scheme?
19:01:25 <blobdata> not really but i program in many other languages...
19:20:03 <jralls> OK. Scheme's a bit of a mind-bender to begin with. It's a dialect of Lisp.
20:13:45 *** Filiaes has joined #gnucash
20:17:46 *** tienne has quit IRC
20:22:50 *** boldstripe has quit IRC
20:40:21 *** oozer has quit IRC
20:41:11 *** marusich has joined #gnucash
20:45:30 *** marusich has quit IRC
20:58:27 *** marusich has joined #gnucash
20:59:44 *** badger92 has quit IRC
20:59:58 *** badger92 has joined #gnucash
21:11:00 *** badger92 has quit IRC
21:11:19 *** badger92 has joined #gnucash
21:12:01 *** badger92 has joined #gnucash
21:30:47 *** storyjesse has joined #gnucash
21:48:32 *** kapil___ has quit IRC
21:51:49 *** Zowlyfon has joined #gnucash
22:14:39 *** kapil___ has joined #gnucash
22:29:45 *** badger92 has quit IRC
22:32:24 *** badger92 has joined #gnucash