David wrote:
Later, you need to add an 'employed' boolean field, to reflect whether
an employee is still working at the company
Your new apps know the difference between employed and unemployed
employee, but old apps all assume that all employees in the table are
currently employed, and will wa
Thanks for you reply.
On Wed, Jun 18, 2008 at 9:15 PM, Shane Ambler <[EMAIL PROTECTED]> wrote:
> David wrote:
>>
>> Hi list.
>>
>> If you have an existing table, and apps which use it, then how do you
>> add new fields to the table (for new apps), but which might affect
>> existing apps negatively
>> Problem with this is that some RDBMS (Postgresql specifically) don't
>> let you run update statements on views.
>
> Given 1) the view will be "fairly uncomplicated" and hence
> "fairly straightforward" ON INSERT/UPDATE/DELETE rule can
> likely be added to it allowing for an apparently writable
>
David wrote:
Hi list.
If you have an existing table, and apps which use it, then how do you
add new fields to the table (for new apps), but which might affect
existing apps negatively?
If you know you are going to add a column then add it now and just not
have your app do anything with any d
On Wed, Jun 18, 2008 at 02:04:14PM +0200, David wrote:
> 1) table1 becomes a view of an updated table, with a 'WHERE field4 IS
> NULL' clause.
>
> Problem with this is that some RDBMS (Postgresql specifically) don't
> let you run update statements on views.
Given 1) the view will be "fairly unco
Hi list.
If you have an existing table, and apps which use it, then how do you
add new fields to the table (for new apps), but which might affect
existing apps negatively?
eg: I start with a table like this:
table1
- id
- field1
- field2
- field3
Later, I want to add a use case, where there
