Re: Updating 1.3 RFC and small bugs

[Chris Travers <..hidden..>]

On Sat, Jun 18, 2011 at 12:55 PM, Erik Huelsmann <..hidden..> wrote:
> Hi John,
>
> On Sat, Jun 18, 2011 at 8:10 PM, John Locke <..hidden..> 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
> ..hidden..
> https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
>