Hi Adrian:
On Sun, Apr 6, 2014 at 5:05 PM, Adrian Klaver <adrian.klaver@aklaver.com> wrote:
> On 04/06/2014 05:30 AM, Francisco Olarte wrote:
>> I think a trigger is overkill for just a simple data-combining
>> procedure. JMO, but I prefere to reserve triggers for htings which
>> need them.
> Well the flip side to that argument is that a trigger is a single point of
> reference for the data changing. You can hit the table from wherever and
> whatever and have the same thing happen. No wrestling with ORMs to get
> database specific code to run. No tracking down where the query is that is
> munging the data. Not saying one approach is inherently better than the
> other, just that there are options.
You raise some notable points. Specially in the ORM wrestling part,
which I never thought of as I hate them. I'm still partial to some
normal logic, perhaps hidden in a procedure which may be invoked on an
instead trigger on inserts of a dedicated view ( data changing insert
triggers scare me, I like to be able to select what I've just
inserted, so I would prefer to insert into a view with only the ids
and extra part and recover the full files from another table / view
).
Although I still think that given his original statement the best
would be to select some values from the sequence, rename the files and
insert them after, or what I did for something similar once, insert
the rows with the original names and then rename the files after
insert, and, after a crash, find leftover unrenamed files, rescan
table for them and rename.
Francisco Olarte.
