On 02/11/10 23:11, Craig Ringer wrote:
On 02/11/10 18:29, Jonathan Tripathy wrote:
I don't really mind what happens, as
long as the user is made aware of what has happen, and there aren’t any
memberships with no corresponding customers.
Well, that's taken care of by a referential integrity c
On 02/11/10 18:29, Jonathan Tripathy wrote:
> I don't really mind what happens, as
> long as the user is made aware of what has happen, and there aren’t any
> memberships with no corresponding customers.
Well, that's taken care of by a referential integrity constraint. You
don't need anything el
On 02/11/10 09:53, Craig Ringer wrote:
On 11/02/2010 03:01 AM, Jonathan Tripathy wrote:
user1 goes to customer page, clicks on "delete membership" of the last
member ship, which blows away the membership,
user2 goes to customer page, clicks on "add membership" and starts
filling out info.
user
On 11/02/2010 03:01 AM, Jonathan Tripathy wrote:
user1 goes to customer page, clicks on "delete membership" of the last
member ship, which blows away the membership,
user2 goes to customer page, clicks on "add membership" and starts
filling out info.
user1 then blows away the customer.
However
On Mon, 01 Nov 2010 20:02:30 +, Jonathan Tripathy
wrote:
> On 01/11/10 19:56, Andy Colson wrote:
>> On 11/1/2010 2:29 PM, Jonathan Tripathy wrote:
>>>
>>> On 01/11/10 19:12, Andy Colson wrote:
On 11/1/2010 2:01 PM, Jonathan Tripathy wrote:
>
>>> I'll give you the exact case where
Andy Colson writes:
> now now we have a membership record (100), but no customer record.
I haven't really been following this thread, but: isn't the answer
to that to establish a foreign-key constraint? If there's an FK
then the database will provide sufficient row locking to prevent
you from de
On 11/1/2010 3:02 PM, Jonathan Tripathy wrote:
On 01/11/10 19:56, Andy Colson wrote:
On 11/1/2010 2:29 PM, Jonathan Tripathy wrote:
On 01/11/10 19:12, Andy Colson wrote:
On 11/1/2010 2:01 PM, Jonathan Tripathy wrote:
I'll give you the exact case where I'm worried:
We have a table of cust
On 01/11/10 19:56, Andy Colson wrote:
On 11/1/2010 2:29 PM, Jonathan Tripathy wrote:
On 01/11/10 19:12, Andy Colson wrote:
On 11/1/2010 2:01 PM, Jonathan Tripathy wrote:
I'll give you the exact case where I'm worried:
We have a table of customers, and each customer can have multiple
membe
On 01/11/10 19:12, Andy Colson wrote:
On 11/1/2010 2:01 PM, Jonathan Tripathy wrote:
I'll give you the exact case where I'm worried:
We have a table of customers, and each customer can have multiple
memberships (which are stored in the memberships table). We want our
deleteMembership(int mem
On 11/1/2010 2:01 PM, Jonathan Tripathy wrote:
I'll give you the exact case where I'm worried:
We have a table of customers, and each customer can have multiple
memberships (which are stored in the memberships table). We want our
deleteMembership(int membershipID) method to remove the membersh
I'll give you the exact case where I'm worried:
We have a table of customers, and each customer can have multiple
memberships (which are stored in the memberships table). We want our
deleteMembership(int membershipID) method to remove the membership, then
check to see if there are no more membe
On 11/1/2010 1:38 PM, Jonathan Tripathy wrote:
Hi Andy,
Thanks for your reply. Would the above code be classed as a single
transaction then?
Yes, assuming there's no explicit transaction control
(COMMIT/ROLLBACK/END) in your queries.
Actually, we do have maybe one or 2 queries that use ROLLB
On 01/11/10 18:38, Jonathan Tripathy wrote:
Hi Andy,
Thanks for your reply. Would the above code be classed as a single
transaction then?
Yes, assuming there's no explicit transaction control
(COMMIT/ROLLBACK/END) in your queries.
Actually, we do have maybe one or 2 queries that use ROLLBACK
Hi Andy,
Thanks for your reply. Would the above code be classed as a single
transaction then?
Yes, assuming there's no explicit transaction control
(COMMIT/ROLLBACK/END) in your queries.
Actually, we do have maybe one or 2 queries that use ROLLBACK, however
ROLLBACK happens at the end of a "c
2010/11/1 Jonathan Tripathy :
>
> On 01/11/10 18:08, Andy Colson wrote:
>>
>> On 11/1/2010 12:37 PM, Jonathan Tripathy wrote:
>>>
>>> Hi Everyone,
>>>
>>> I'm trying to create a server for a database system which will be used
>>> by multiple clients. Of course, table locking is very important. Read
On 11/1/2010 12:37 PM, Jonathan Tripathy wrote:
Hi Everyone,
I'm trying to create a server for a database system which will be used
by multiple clients. Of course, table locking is very important. Reading
the Postgresql docs, locking occurs on a transaction-by-transaction basis.
In our java cod
On 01/11/10 18:08, Andy Colson wrote:
On 11/1/2010 12:37 PM, Jonathan Tripathy wrote:
Hi Everyone,
I'm trying to create a server for a database system which will be used
by multiple clients. Of course, table locking is very important. Reading
the Postgresql docs, locking occurs on a transactio
Hi Everyone,
I'm trying to create a server for a database system which will be used
by multiple clients. Of course, table locking is very important. Reading
the Postgresql docs, locking occurs on a transaction-by-transaction basis.
In our java code, we are doing this:
//Start Code Block
Con
18 matches
Mail list logo
