Project

General

Profile

« Previous | Next » 

Revision 3163

schemas/vegbien.sql: location: Dropped unique constraint on lat/long because it covered only some rows, which interfered with column-based import's selection of different insert methods based on the presence or absence of duplicate keys. (With the constraint, locations with coordinates would have duplicates eliminated, but locations without coordinates would not be able to find which row was added for a particular location because there was no lookup key to join on, and would all just use the first inserted row.) The previous behavior didn't make much sense anyway, because it would assert that two locationevents occurred in the same place just because they had the same coordinates, which may not have been precise enough to make this determination. Asserting that two locationevents occurred in the same place is really part of the secondary validation, not the import process.

View differences:

vegbien.sql
3646 3646

  
3647 3647

  
3648 3648
--
3649
-- Name: location_unique_coords; Type: CONSTRAINT; Schema: public; Owner: -; Tablespace: 
3650
--
3651

  
3652
ALTER TABLE ONLY location
3653
    ADD CONSTRAINT location_unique_coords UNIQUE (centerlatitude, centerlongitude);
3654

  
3655

  
3656
--
3657 3649
-- Name: location_unique_subplot_coords; Type: CONSTRAINT; Schema: public; Owner: -; Tablespace: 
3658 3650
--
3659 3651

  
......
4676 4668

  
4677 4669

  
4678 4670
--
4679
-- Name: location_coords; Type: INDEX; Schema: public; Owner: -; Tablespace: 
4680
--
4681

  
4682
CREATE INDEX location_coords ON location USING btree ((COALESCE(centerlatitude, 'NaN'::double precision)), (COALESCE(centerlongitude, 'NaN'::double precision)));
4683

  
4684

  
4685
--
4686 4671
-- Name: location_parent_id_x; Type: INDEX; Schema: public; Owner: -; Tablespace: 
4687 4672
--
4688 4673

  

Also available in: Unified diff