yes, I can use a view. forEachRow also records what failed. Updating a view requires a trigger, but I can compose one with the view.
Thank you for suggestion! Roman ________________________________________ From: sqlite-users [sqlite-users-boun...@mailinglists.sqlite.org] on behalf of Richard Damon [rich...@damon-family.org] Sent: Friday, January 26, 2018 6:50 PM To: sqlite-users@mailinglists.sqlite.org Subject: Re: [sqlite] primary key in another column Couldn't you have it access a view which adds the columns by calculation rather than the raw table? (and if you have some tables that don't need such a view, create a simple pass through view). On 1/26/18 6:30 PM, Roman Fleysher wrote: > No, I can not compute inside forEachRow. ForEachRow is now universal, can be > applied to any table. If I modify SELECT inside it to fit specific purpose, > forEachRow will use universality. > > Roman > > ________________________________________ > From: sqlite-users [sqlite-users-boun...@mailinglists.sqlite.org] on behalf > of Richard Damon [rich...@damon-family.org] > Sent: Friday, January 26, 2018 6:26 PM > To: sqlite-users@mailinglists.sqlite.org > Subject: Re: [sqlite] primary key in another column > > One question I have, couldn't you just omit the fileName column from the > able, and compute it in the select query that is getting the data? > > On 1/26/18 6:03 PM, Roman Fleysher wrote: >> My implementation of "for Each row" requires all columns to be populated. >> It is a dumb thing: >> >> forEachRow commandToBeExecuted itsArgumentsWhichReferToColumns >> >> The files are images. Example: >> >> forEachRow addImages outputColumn column1 column2 >> >> ForEachRow will loop over the rows (in parallel batches if it can) and apply >> the command given to it with its arguments. Image processing is then a >> sequence of these "forEach" commands. >> >> >> Roman >> >> On 1/26/2018 5:47 PM, Roman Fleysher wrote: >>> I will use this table as a manager. There will be multiple columns holding >>> various file names. The names can be random, but I want humans to be able >>> to easily inspect. After table is filled, an operation "for each row" will >>> get files in some columns and produce files in other columns. This is done >>> outside of SQLite. "For each row" will process several rows in parallel >>> because they are independent. Some operations might fail and will be >>> recored in the proper columns. After all the work is done, the manager >>> table is discarded. >> I'm still not sure I understand, but: while you are building out this >> manager table, can't you leave fileName column blank, and then right before >> processing, run UPDATE A SET fileName='prefix_'||ID; on it? >> -- >> Igor Tandetnik > -- > Richard Damon > > _______________________________________________ > sqlite-users mailing list > sqlite-users@mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users > _______________________________________________ > sqlite-users mailing list > sqlite-users@mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users -- Richard Damon _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
