Re: [Ledger-smb-devel] Updating 1.3 RFC and small bugs
On 06/18/2011 04:23 PM, Chris Travers wrote:
On Sat, Jun 18, 2011 at 12:55 PM, Erik Huelsmann ehu...@gmail.com wrote:
Hi John,
On Sat, Jun 18, 2011 at 8:10 PM, John Locke m...@freelock.com wrote:
Hi,
After a couple weeks away from bookkeeping, doing some catchup now. Just
pulled down the latest trunk, and merged them in.
I see the new sql/upgrade directory, which strikes me as a great direction
to go. I like the naming of sql update scripts with svn id, and I'd like to
take it one step further: keep a value in the defaults table for the
latest db updates.
I just did the following:
INSERT INTO defaults VALUES ('schema_version', '3273');
... since that looks like the largest svn id with a change under sql.
As the first part of scripting updates, it would be really great to have
each schema change dropped into an update sql script in sql/upgrade, with
the svn id in the file name. And part of the script would be updating the
schema_version in defaults (which should get initially set in
Pg-database.sql).
I just spent 2 hours applying schema updates... would be so much easier to
just import a few sql files. (granted, much of that was fixing underlying
data issues uncovered by adding unique keys...).
Very nice idea. I wonder how to take this further: Chris seems to have
started with that directory, but I have no idea how we should maintain
it, or if there's anything we could do to make it easy or enforced to
update the updates/ directory too.
My thinking is that any time DDL changes unless it is just the
internals of a function (where the sl file can be reloaded), we should
have a file to accommodate that change.Every biweekly release can
also have a psql script which loads changed function definitions since
last snapshot. I think the convention should be [svn
revi]_description.sql
This much sounds good... but there's still the issue of knowing which
sql files need to get reloaded. This is where I think we need a schema
version, and some sort of convention for knowing when an sql file gets
changed (other than timestamps/commit logs).
I can think of two different reasonable approaches:
1. Parseable change log that can be used by an update function.
2. Index file of schema id of the last change to each sql file.
First off, the schema version -- I propose we make it related to svn id,
without requiring it to be exact. Committers will need to be careful
when updating trunk to make sure they increase the number and include
all changes -- which is where commit id makes sense. But in practice, in
update scripts, I think the main thing to care about is whether the
schema version is bigger than the one currently in the database.
For approach 1, I would see writing update functions similar to Drupal,
with the schema id in the name. The function could load any updated sql
files, as well as insert new ones. Some controller function can parse
the file, find all update functions bigger than the current schema file,
and execute them.
For approach 2, I see creating a hash of all the sql files, each with
the most recent schema version containing a change to that file. Then
our update function could just look for sql files with a bigger schema
version and reload them.
Thoughts?
Cheers,
John Locke
http://freelock.com
--
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev
___
Ledger-smb-devel mailing list
Ledger-smb-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
[Ledger-smb-devel] Updating 1.3 RFC and small bugs
Hi,
After a couple weeks away from bookkeeping, doing some catchup now. Just
pulled down the latest trunk, and merged them in.
I see the new sql/upgrade directory, which strikes me as a great
direction to go. I like the naming of sql update scripts with svn id,
and I'd like to take it one step further: keep a value in the defaults
table for the latest db updates.
I just did the following:
INSERT INTO defaults VALUES ('schema_version', '3273');
... since that looks like the largest svn id with a change under sql.
As the first part of scripting updates, it would be really great to have
each schema change dropped into an update sql script in sql/upgrade,
with the svn id in the file name. And part of the script would be
updating the schema_version in defaults (which should get initially set
in Pg-database.sql).
I just spent 2 hours applying schema updates... would be so much easier
to just import a few sql files. (granted, much of that was fixing
underlying data issues uncovered by adding unique keys...).
Part 2: Issues I'm hitting.
Just trying to jot down the things I'm hitting today:
Issue 1: Permission needed on partstax relation.
Repro: 1. update menu_acl system, regenerate roles file, re-import
roles. Go to Goods and Services - Reports - All Parts, find an
existing part. Attempt to add an existing tax to the part. Result:
Error!
*DELETE FROM partstax WHERE parts_id = ?
ERROR: permission denied for relation partstax*
... Looks like lsmb_dbname__part_create needs to be granted delete on
partstax...
Issue 2: AR - Customers - Search is case-sensitive. Change search
function to use ~ or ILIKE instead of LIKE.
More to come...
Cheers,
John
--
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev___
Ledger-smb-devel mailing list
Ledger-smb-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
Re: [Ledger-smb-devel] Updating 1.3 RFC and small bugs
Hi John,
On Sat, Jun 18, 2011 at 8:10 PM, John Locke m...@freelock.com wrote:
Hi,
After a couple weeks away from bookkeeping, doing some catchup now. Just
pulled down the latest trunk, and merged them in.
I see the new sql/upgrade directory, which strikes me as a great direction
to go. I like the naming of sql update scripts with svn id, and I'd like to
take it one step further: keep a value in the defaults table for the
latest db updates.
I just did the following:
INSERT INTO defaults VALUES ('schema_version', '3273');
... since that looks like the largest svn id with a change under sql.
As the first part of scripting updates, it would be really great to have
each schema change dropped into an update sql script in sql/upgrade, with
the svn id in the file name. And part of the script would be updating the
schema_version in defaults (which should get initially set in
Pg-database.sql).
I just spent 2 hours applying schema updates... would be so much easier to
just import a few sql files. (granted, much of that was fixing underlying
data issues uncovered by adding unique keys...).
Very nice idea. I wonder how to take this further: Chris seems to have
started with that directory, but I have no idea how we should maintain
it, or if there's anything we could do to make it easy or enforced to
update the updates/ directory too.
Part 2: Issues I'm hitting.
Just trying to jot down the things I'm hitting today:
Issue 1: Permission needed on partstax relation.
Repro: 1. update menu_acl system, regenerate roles file, re-import roles. Go
to Goods and Services - Reports - All Parts, find an existing part.
Attempt to add an existing tax to the part. Result:
Error!
DELETE FROM partstax WHERE parts_id = ?
ERROR: permission denied for relation partstax
... Looks like lsmb_dbname__part_create needs to be granted delete on
partstax...
Hmm. I wonder if we should not just have a _part_edit role which
should be given the required DELETE access. [Told you in IRC already,
but putting here for general consumption by all interested.]
Issue 2: AR - Customers - Search is case-sensitive. Change search function
to use ~ or ILIKE instead of LIKE.
r3281.
Bye,
Erik.
--
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev
___
Ledger-smb-devel mailing list
Ledger-smb-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
Re: [Ledger-smb-devel] Updating 1.3 RFC and small bugs
Part 2: Issues I'm hitting. Just trying to jot down the things I'm hitting today: Issue 1: Permission needed on partstax relation. Registered as 3321966. Bye, Erik. -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev ___ Ledger-smb-devel mailing list Ledger-smb-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
Re: [Ledger-smb-devel] Updating 1.3 RFC and small bugs
On Sat, Jun 18, 2011 at 12:55 PM, Erik Huelsmann ehu...@gmail.com wrote:
Hi John,
On Sat, Jun 18, 2011 at 8:10 PM, John Locke m...@freelock.com wrote:
Hi,
After a couple weeks away from bookkeeping, doing some catchup now. Just
pulled down the latest trunk, and merged them in.
I see the new sql/upgrade directory, which strikes me as a great direction
to go. I like the naming of sql update scripts with svn id, and I'd like to
take it one step further: keep a value in the defaults table for the
latest db updates.
I just did the following:
INSERT INTO defaults VALUES ('schema_version', '3273');
... since that looks like the largest svn id with a change under sql.
As the first part of scripting updates, it would be really great to have
each schema change dropped into an update sql script in sql/upgrade, with
the svn id in the file name. And part of the script would be updating the
schema_version in defaults (which should get initially set in
Pg-database.sql).
I just spent 2 hours applying schema updates... would be so much easier to
just import a few sql files. (granted, much of that was fixing underlying
data issues uncovered by adding unique keys...).
Very nice idea. I wonder how to take this further: Chris seems to have
started with that directory, but I have no idea how we should maintain
it, or if there's anything we could do to make it easy or enforced to
update the updates/ directory too.
My thinking is that any time DDL changes unless it is just the
internals of a function (where the sl file can be reloaded), we should
have a file to accommodate that change.Every biweekly release can
also have a psql script which loads changed function definitions since
last snapshot. I think the convention should be [svn
revi]_description.sql
Part 2: Issues I'm hitting.
Just trying to jot down the things I'm hitting today:
Issue 1: Permission needed on partstax relation.
Repro: 1. update menu_acl system, regenerate roles file, re-import roles. Go
to Goods and Services - Reports - All Parts, find an existing part.
Attempt to add an existing tax to the part. Result:
Error!
DELETE FROM partstax WHERE parts_id = ?
ERROR: permission denied for relation partstax
... Looks like lsmb_dbname__part_create needs to be granted delete on
partstax...
Hmm. I wonder if we should not just have a _part_edit role which
should be given the required DELETE access. [Told you in IRC already,
but putting here for general consumption by all interested.]
probably a good idea.
Issue 2: AR - Customers - Search is case-sensitive. Change search function
to use ~ or ILIKE instead of LIKE.
r3281.
Bye,
Erik.
--
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev
___
Ledger-smb-devel mailing list
Ledger-smb-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
--
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev
___
Ledger-smb-devel mailing list
Ledger-smb-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
