On Mon, Mar 8, 2010 at 4:08 PM, Adam Thompson wrote:
> Oh. That bites. And I see CHECK has even worse limitations. So much
> for that idea.
>
>> Also, I would wonder what the performance of a deferred check
>> constraint that was something like sum(amount) = 0 on the journal line
>> table woul
Chris Travers wrote:
> I am going to make another suggestion here. We should probably
> suggest that no reporting functions should run as security definer.
> This allows the same data to be accessed relationally as would be
> retrieved by the function.
I'd like to see the project go one step furt
Chris Travers wrote:
> I would love to use DEFER more. Unfortunately, from the Pg 8.4 manual:
> "Only foreign key constraints currently accept this clause. All other
> constraint types are not deferrable."
>
> In fact only foreign key constraints which are "NO ACTION" can be
> deferred..
Oh.
As an example of what's wrong with using sprocs to enforce security
Of course we have to do this for managing users, and user
creation/alteration commands are not parameterized.
So suppose you do something like this (simplified version):
CREATE OR REPLACE FUNCTION create_user(in_username tex
On Mon, Mar 8, 2010 at 11:21 AM, Adam Thompson wrote:
>> Many of the data integrity constraints can be embedded as CHECK or
>> referential constraints in the database schema; this alone can minimize the
>> *possibility* of someone changing data in the wrong way. For those
>> transactions that
mussen
> To: Development discussion for LedgerSMB
> ReplyTo: Development discussion for LedgerSMB
> Subject: Re: [Ledger-smb-devel] Proposal for 2.0: SODA 2.0
> Sent: Mar 8, 2010 12:42
>
>> I can't speak for Chris, but from my point of view, putting everything
>> in th
Kaare Rasmussen wrote:
>> I can't speak for Chris, but from my point of view, putting everything
>> in the DB is nice because it lets me use $FAVORITE_LANGUAGE to access
>> the database, where $FAVORITE_LANGUAGE may or may not be Perl.
> That's what REST (or webservices) are for. ISTM that you wa
nformation.
--Original Message--
From: Kaare Rasmussen
To: Development discussion for LedgerSMB
ReplyTo: Development discussion for LedgerSMB
Subject: Re: [Ledger-smb-devel] Proposal for 2.0: SODA 2.0
Sent: Mar 8, 2010 12:42
> I can't speak for Chris, but from my point of view, putting everyth
> I can't speak for Chris, but from my point of view, putting everything
> in the DB is nice because it lets me use $FAVORITE_LANGUAGE to access
> the database, where $FAVORITE_LANGUAGE may or may not be Perl.
That's what REST (or webservices) are for. ISTM that you want to replace a
perl api wit
On Mon, Mar 8, 2010 at 11:12 AM, Aurynn Shaw wrote:
> The database tables should be likened to private methods and
> datastructures of an object - they're hidden, and exposed via an API
> interface, which allows for deep refactoring of underlying concepts
> without breaking other applications. Ha
) an object store or flat files.
*sigh* I have more to say, but my thumbs are getting sore (typing on a
blackberry).
-Adam
-Original Message-
From: Aurynn Shaw
Date: Mon, 08 Mar 2010 11:12:48
To: Development discussion for LedgerSMB
Subject: Re: [Ledger-smb-devel] Proposal for 2.0: SODA
Many of the data integrity constraints can be embedded as CHECK or referential
constraints in the database schema; this alone can minimize the *possibility*
of someone changing data in the wrong way. For those transactions that have to
be multi-step, e.g. GL transactions, it makes perfect sense
On 10-03-08 10:11 AM, Luke wrote:
> On Mon, 8 Mar 2010, Adam Thompson wrote:
>
>> I'm wondering why the push to move so much functionality into the DB
>> instead of using an ORM, which seems to be where you're headed anyway?
>> Or, to rephrase that: if you don't want an ORM in the Perl framework,
>
On Mon, Mar 8, 2010 at 10:11 AM, Luke wrote:
> On Mon, 8 Mar 2010, Adam Thompson wrote:
>
> Since I find myself agreeing with this to a certain extent, I will chime
> in on something I would have otherwise remained out of.
>
> First of all, I will say that I am not clear on the programming for wha
On Mon, 8 Mar 2010, Adam Thompson wrote:
> I'm wondering why the push to move so much functionality into the DB
> instead of using an ORM, which seems to be where you're headed anyway?
> Or, to rephrase that: if you don't want an ORM in the Perl framework,
> why are you trying to build one in t
I am going to make another suggestion here. We should probably
suggest that no reporting functions should run as security definer.
This allows the same data to be accessed relationally as would be
retrieved by the function.
Best Wishes,
Chris Travers
-
On Mon, Mar 8, 2010 at 8:21 AM, Adam Thompson wrote:
> I'm wondering why the push to move so much functionality into the DB instead
> of using an ORM, which seems to be where you're headed anyway?
> Or, to rephrase that: if you don't want an ORM in the Perl framework, why are
> you trying to bui
On Mon, Mar 8, 2010 at 8:36 AM, David F. Skoll wrote:
> Adam Thompson wrote:
>
>> I'm wondering why the push to move so much functionality into the DB
>> instead of using an ORM, which seems to be where you're headed
>> anyway?
>
> I can't speak for Chris, but from my point of view, putting everyt
Adam Thompson wrote:
> I'm wondering why the push to move so much functionality into the DB
> instead of using an ORM, which seems to be where you're headed
> anyway?
I can't speak for Chris, but from my point of view, putting everything
in the DB is nice because it lets me use $FAVORITE_LANGUAGE
, 8 Mar 2010 08:11:51
To: Development discussion for LedgerSMB
Subject: [Ledger-smb-devel] Proposal for 2.0: SODA 2.0
This proposal covers our service oriented database architecture and
how I am proposing it changes for 2.0. Some of these changes require
PostgreSQL 8.4 and reasonably recent DBD::Pg to
This proposal covers our service oriented database architecture and
how I am proposing it changes for 2.0. Some of these changes require
PostgreSQL 8.4 and reasonably recent DBD::Pg to work, and they
represent substantial changes in interface from 1.3.
1) Rich Data Type Definitions
Custom types
21 matches
Mail list logo
