26 Jul
2019
26 Jul
'19
9:18 p.m.
Hi,
In my current installation of LedgerSMB, the tables are in a schema other
than public, because I installed it in a database where there are other
data in schema public. (The reason I did that is that I want to link tables
in schema public and LedgerSMB tables, but I have not done it yet.)
I could make it work relatively painlessly with LedgerSMB 1.3 by setting
db_namespace in ledgersmb.conf.
Recently (that is, very late!) I wanted to upgrade to LedgerSMB 1.5.24
(not 1.6 because my server is still under Debian stretch). I think I could
upgrade the database correctly with setup.pl, but when running login.pl it
will not work because, according to Postgresql's logs, it insists on trying
to call the stored procedure public.setting_get, which does not exist.
Although I do not know perl, I tried to read the code to understand what
is going on. If I understood well, stored procedures are called by calling
directly or indirectly the perl function call_procedure in module PGObject,
which sets the schema to public when it is not specified. However, module
LedgerSMB also contains a function call_procedure which correctly sets the
schema, so the problem seems to be that sometimes PGObject's call_procedure
is called directly instead of module LedgerSMB's. I do not understand why,
because I do not know what constructs like $self->call_procedure or
__PACKAGE__->call_procedure do, but anyway this is very annoying for me,
because it means that LedgerSMB 1.5 just will not work with db_namespace
set to anything else than public.
Was this problem known? Is it corrected in a later version?
Regards.
28 Jul
28 Jul
7:22 p.m.
New subject: Running LedgerSMB 1.5 with a schema other than public
Hi Nicolas,
Thanks for writing about your problem!
In my current installation of LedgerSMB, the tables are in a schema other
than public, because I installed it in a database
where there are other
data in schema public. (The reason I did that is that I want to link tables
in schema public and LedgerSMB tables, but I have not done it yet.)
No problem. Your setup *should* be supported. And I remember helping you
when you first set up your database with the non-public schema.
I could make it work relatively painlessly with
LedgerSMB 1.3 by setting
db_namespace in ledgersmb.conf.
Actually, you should still be able to do that. However, I think the section
in which the key resides has changed. Does your ledgersmb.conf have this:
[database]
db_namespace = alternativeschema
?
That is, is your db_namespace in the "database" section of the config file?
Recently (that is, very late!) I wanted to upgrade
to LedgerSMB 1.5.24
(not 1.6 because my server is still under Debian stretch). I think I could
upgrade the database correctly with setup.pl, but when running login.pl it
will not work because, according to Postgresql's logs, it insists on trying
to call the stored procedure public.setting_get, which does not exist.
Thanks for this info. I think I found that the module which calls the
'setting_get' (lib/LedgerSMB/PGOld.pm) to be lacking the code to set up the
db_namespace. I'm now trying to figure out what the best way is to pass the
configuration value to the database call component.
Although I do not know perl, I tried to read the
code to understand what
is going on. If I understood well, stored procedures are called by calling
directly or indirectly the perl function call_procedure in module PGObject,
which sets the schema to public when it is not specified. However, module
LedgerSMB also contains a function call_procedure which correctly sets the
schema, so the problem seems to be that sometimes PGObject's call_procedure
is called directly instead of module LedgerSMB's.
That's a completely correct assessment! The component that's missing to
pass the argument is lib/LedgerSMB/PGOld.pm.
I do not understand why,
because I do not know what constructs like $self->call_procedure or
__PACKAGE__->call_procedure do, but anyway this is very annoying for me,
because it means that LedgerSMB 1.5 just will not work with db_namespace
set to anything else than public.
Was this problem known? Is it corrected in a later version?
Is it a known problem? No, I wasn't aware of it. (And by extension, it's
not fixed in any currently released versions.)
I want to help you by getting this fixed - in a 1.5 release. However, the
last two weeks, I've had very little time to work on this project and my
family duties due to a major release at $work. Would it be ok for you if we
(you and I) were able to work out the complete and correct solution over
the coming weeks? (Then, I'd expect you to have a working solution before
the end of august.) Or is this currently blocking your $getting_work_done ?
Regards,
--
Bye,
Erik.
http://efficito.com -- Hosted accounting and ERP.
Robust and Flexible. No vendor lock-in.
2 Aug
2 Aug
7 a.m.
New subject: Running LedgerSMB 1.5 with a schema other than public
Hi Nicolas,
On Sun, Jul 28, 2019 at 9:22 PM Erik Huelsmann <ehuels(a)gmail.com> wrote:
I've created a change to the code base which is at least a step in the
right direction. Could you check that it works when you place these files
on your server:
https://github.com/ledgersmb/LedgerSMB/blob/8f5782ee9fe2e6159f42b652fd77c33…
https://github.com/ledgersmb/LedgerSMB/blob/8f5782ee9fe2e6159f42b652fd77c33…
?
There should be files on your system with the names
"lib/LedgerSMB/PGOld.pm" and "lib/LedgerSMB/PGObject.pm". Make a
backup of
those files before you do anything, so you can restore your system to what
it was. Then, download the two files above and replace the files you just
backed up. Then restart your server processes (LedgerSMB service) and try
to log in after that.
If you still have problems, please let me know which ones and I'll work to
resolve those too. If you need help applying the fix, don't hesitate to
mail or come to IRC/Matrix for help.
Regards,
--
Bye,
Erik.
http://efficito.com -- Hosted accounting and ERP.
Robust and Flexible. No vendor lock-in.
Recently (that is, very late!) I wanted to
upgrade to LedgerSMB 1.5.24
(not 1.6 because my server is still under Debian stretch). I think I could
upgrade the database correctly with setup.pl, but when running login.pl
it
will not work because, according to Postgresql's logs, it insists on
trying
to call the stored procedure public.setting_get, which does not exist.
Thanks for this info. I think I found that the module which calls the
'setting_get' (lib/LedgerSMB/PGOld.pm) to be lacking the code to set up the
db_namespace. I'm now trying to figure out what the best way is to pass the
configuration value to the database call component.
13 Aug
13 Aug
7:02 p.m.
New subject: Running LedgerSMB 1.5 with a schema other than public
Erik Huelsmann a écrit :
I've created a change to the code base which is at
least a step in the right
direction. Could you check that it works when you place these files on your
server:
https://github.com/ledgersmb/LedgerSMB/blob/
8f5782ee9fe2e6159f42b652fd77c331dd25a737/lib/LedgerSMB/PGOld.pm
https://github.com/ledgersmb/LedgerSMB/blob/
8f5782ee9fe2e6159f42b652fd77c331dd25a737/lib/LedgerSMB/PGObject.pm
?
Hi,
It seems to work, thank you !
I found other places where schema public explicitely appears :
* In sql/changes/1.5/open_forms_callers.sql, there are three requests
explicitely mentioning table « public.open_forms ». This prevents the
complete upgrade of the tables from 1.3 to 1.5. I patched the file by
suppressing « public. » and it works.
* In sql/modules/Roles.sql, there is a request « GRANT ALL ON SCHEMA
public TO public; ».
Regards.
7:40 p.m.
New subject: Running LedgerSMB 1.5 with a schema other than public
On Tue, Aug 13, 2019 at 9:02 PM Nicolas Couchoud <
nicolas.couchoud__ledgersmb(a)normalesup.org> wrote:
Erik Huelsmann a écrit :
Great! Thanks for the confirmation. I can make the suggested adjustments
and merge the branch to make a new release.
I've created a change to the code base which
is at least a step in the
right
direction. Could you check that it works when you
place these files on
your
server:
https://github.com/ledgersmb/LedgerSMB/blob/
8f5782ee9fe2e6159f42b652fd77c331dd25a737/lib/LedgerSMB/PGOld.pm
https://github.com/ledgersmb/LedgerSMB/blob/
8f5782ee9fe2e6159f42b652fd77c331dd25a737/lib/LedgerSMB/PGObject.pm
?
Hi,
It seems to work, thank you !
I found other places where schema public explicitely
appears :
* In sql/changes/1.5/open_forms_callers.sql, there are three requests
explicitely mentioning table « public.open_forms ». This prevents the
complete upgrade of the tables from 1.3 to 1.5. I patched the file by
suppressing « public. » and it works.
Hmm. Ok. In order to prevent future updates from going breaking on your
database, I need a bit of information from you: In your database, there's a
table called "db_patches". This table has a 'sha' and a 'path'
column. I
need the content of the 'sha' column for each of the files you patched
(indicated in the 'path' column). Could you send me the sha of that file? I
want to see if I can recreate the same SHA. (or that I need to send you a
new sha for that column...)
* In sql/modules/Roles.sql, there is a request « GRANT
ALL ON SCHEMA
public TO public; ».
I'll update that one too.
Thanks again!
Regards,
--
Bye,
Erik.
http://efficito.com -- Hosted accounting and ERP.
Robust and Flexible. No vendor lock-in.
18 Aug
18 Aug
1:24 p.m.
New subject: Running LedgerSMB 1.5 with a schema other than public
Erik Huelsmann a écrit :
On Tue, Aug 13, 2019 at 9:02 PM Nicolas Couchoud <
nicolas.couchoud__ledgersmb(a)normalesup.org> wrote:
I found other places where schema public explicitely appears :
* In sql/changes/1.5/open_forms_callers.sql, there are three requests
explicitely mentioning table « public.open_forms ». This prevents the
complete upgrade of the tables from 1.3 to 1.5. I patched the file by
suppressing « public. » and it works.
Hmm. Ok. In order to prevent future updates from going breaking on your
database, I need a bit of information from you: In your database, there's
a table called "db_patches". This table has a 'sha' and a
'path' column.
I need the content of the 'sha' column for each of the files you patched
(indicated in the 'path' column). Could you send me the sha of that file?
I want to see if I can recreate the same SHA. (or that I need to send you
a new sha for that column...)
The only file I patched in direcftory sql/changes is
sql/changes/1.5/open_forms_callers.sql . The corresponding sha column in
table db_patches is
ke63Vj9L87jBNBhn3SgzIAtT2WQ3GBjowM24pRtt4H1a13PmUd3hW9T+VQCsPUF2UDXWs9pMIPbOEE/l7kNROA
In my patched file I added a comment in French so it may be difficult for
you to obtain the same sha.
Regards.
2:53 p.m.
New subject: Running LedgerSMB 1.5 with a schema other than public
Hi Nicolas,
On Sun, Aug 18, 2019 at 3:24 PM Nicolas Couchoud <
nicolas.couchoud__ledgersmb(a)normalesup.org> wrote:
[ snip ]
Thanks for sending the SHA, I was just working on completing the change and
the builders are running to verify the commits.
We thought beforehand that it would be hard to maintain the exact same
content of the files over time -- either because of space-reformatting or
because we (or someone else--like you) would feel or even have the need to
add comments. So: as it happens, the SHA of the file I prepared in the
commit that's being verified *matches* yours!
Regards,
--
Bye,
Erik.
http://efficito.com -- Hosted accounting and ERP.
Robust and Flexible. No vendor lock-in.
I need the
content of the 'sha' column for each of the files you patched
(indicated in the 'path' column). Could you send me the sha of that file?
I want to see if I can recreate the same SHA. (or that I need to send you
a new sha for that column...)
The only file I patched in direcftory sql/changes is
sql/changes/1.5/open_forms_callers.sql . The corresponding sha column in
table db_patches is
ke63Vj9L87jBNBhn3SgzIAtT2WQ3GBjowM24pRtt4H1a13PmUd3hW9T+VQCsPUF2UDXWs9pMIPbOEE/l7kNROA
In my patched file I added a comment in French so it may be difficult for
you to obtain the same sha.
1507
days inactive
1530
days old
6 comments
2 participants
participants (2)
-
Erik Huelsmann -
Nicolas Couchoud