Ok... I'd sure like to think about this a little more...
If you can think of any other special cases that should be handled w/ care
in csv import (besides unique fields) please point them out.
On Mon, Mar 9, 2009 at 11:40 PM, ceej <cjlaz...@googlemail.com> wrote:
>
> That's what I was meaning :)
>
> On Mar 9, 11:05 pm, Yarko Tymciurak <yark...@gmail.com> wrote:
> > I think this is dangerous at all sorts of levels.... I personally do not
> > think this is a good idea.
> > Having looked at the handy thing Massimo did, where if a field is called
> > "uuid" (magic field name???? well - that part I definitely do NOT like
> ---
> > side-effect)
> >
> > the concept that a field/column that (what I want to change this to) is
> > CREATED with unique=True attribute, that is it is not the "id" field that
> is
> > automatically used in potentially unforseeable ways by DAL --- that is a
> > unique field of your own control, is intentional -
> >
> > that the behavior which Massimo already has put in (but only on a
> "magic"
> > field name, without - at present - any checks for uniquness) ---
> >
> > the current behavior which is:
> >
> > "if you give me a uniq field name with a value that already exists in the
> > db, I will update that row" ---
> >
> > is useful, automatic, and all that I would prefer to see is an update to
> > actually check that if the name of a field you tell this function is
> unique,
> > actually IS
> >
> > that way in the data table definition (that is the "guarentee") then the
> > behavior as it is currently coded should be followed (e.g. update if the
> > filed already exists on that unique key, else create the row).
> >
> > I would have the "uniq" name default be NULL so that this behavior is
> NEVER
> > followed, unless you EXPLICITLY ASK FOR IT (that, again, is because I
> > _really_ don't like unexpected side effects).
> >
> > The only thing left to think about: if you DO NOT ask for updates, and a
> > uniq=True field exists, what would be the proper, normal behavior? I
> > suggest that as it works NOW for "id" (that is, the id value is ignored,
> and
> > a new entry is made) would probably be good.
> >
> > For that matter, with these constraints, if you INTEND to update based on
> ID
> > - why not allow that too (under the same rules) --- if you INTEND to
> trigger
> > it, then we assume you KNOW what you are doing, and accept the data
> > consequences.
> >
> > How does this sound?
> >
> > (I've been rather thinking out loud).
> >
> > Regards,
> > Yarko
> >
> >
> >
> > On Mon, Mar 9, 2009 at 12:41 PM, ceej <cjlaz...@googlemail.com> wrote:
> >
> > > I'm just saying when it comes to not using CSV import feature we
> > > should make it possible to do keep_in_sync_row=db.your_table.insert
> > > (id=my_own_id,name='test')
> >
> > > On Mar 8, 6:52 pm, Yarko Tymciurak <yark...@gmail.com> wrote:
> > > > On Sun, Mar 8, 2009 at 3:05 PM, ceej <cjlaz...@googlemail.com>
> wrote:
> >
> > > > > How would this apply not using csv and doing a manual
> > > > > keep_in_sync_row=db.your_table.insert(id=my_own_id,name='test') ?
> >
> > > > Not sure what you are saying, ceej....
> >
> > > > > On Mar 7, 8:12 pm, mdipierro <mdipie...@cs.depaul.edu> wrote:
> > > > > > If the table has a field called "uuid" it is used and the record
> is
> > > > > > inserted or updated accordingly.
> >
> > > > Massimo: currently the code in
> > > gluon/sql.py/table::import_from_csv_file()
> > > > is a little confusing / hard to read properly.
> >
> > > > As is is written, there is a check for a local variable "unique"
> > > > (unfortunate that this is the same as an attribute name on a column
> in
> > > DAL),
> > > > which by default is set to "uuid".
> >
> > > > The way this seems to work is if the TABLE FIELD is NAMED "uuid" (by
> > > > default) AND the row[column_name] value presented in the csv already
> > > exists
> > > > in the table, then this will update the existing row (not sure what
> will
> > > > happen is the row/column is marked unique=True in DAL, and you try to
> > > pass
> > > > an update to that column - even with the same data value; I worry
> this
> > > may
> > > > be problematic in general -- but maybe not...).
> >
> > > > There's another problem with this code: since in that code, this:
> >
> > > > if self._db(self._db[self][unique]==_unique).count():
> >
> > > > does not check if count is > 1 (only != 0), and since there is check
> that
> > > > the data table has unique=True constraint on it, the following
> update:
> >
> > > > self._db(self[unique]==_unique).update(**dict(items))
> >
> > > > may update update may fail in any of several ways: it may update
> more
> > > than
> > > > one column, for example.
> >
> > > > There are several ways to handle this, one being that this code
> should
> > > > confirm that the selected column has the unique=True set.
> >
> > > > for i in self.fields:
> > > > if self[i].unique == True
> > > > # then tag this as a potential update field
> > > > # ... or optionally, if this matches the unique local
> variable,
> > > > # ... and that column has the unique attribute set - but
> ths
> > > begs
> > > > the question
> > > > # what should this do? I think unique= flag to this
> function
> > > > should be True/False --
> > > > # and mark this: to check for unique fields, and if so
> process
> > > as
> > > > the rest of this code does...
> >
> > > > > > Massimo
> >
> > > > > > On Mar 7, 6:31 pm, Yarko Tymciurak <yark...@gmail.com> wrote:
> >
> > > > > > > This is really great - it only leaves the use case I outlined -
> > > > > updating
> > > > > > > rows from csv (or - in the case of UUID / name field of coupon,
> > > would
> > > > > this
> > > > > > > work that way anyway? Actually, I think so....)
> >
> > > > > > > On Sat, Mar 7, 2009 at 3:15 PM, mdipierro <
> mdipie...@cs.depaul.edu
> >
> > > > > wrote:
> >
> > > > > > > > Actually if you restore multiple tables using
> >
> > > > > > > > d={}
> > > > > > > > db.table1.import_from_csv_file(file1,d)
> > > > > > > > db.table2.import_from_csv_file(file3,d)
> > > > > > > > ...
> >
> > > > > > > > web2py WILL FIX all your references. The new id will not be
> the
> > > same
> > > > > > > > as the old ones but the references will reflect the new ids.
> > > > > > > > This is achieved by storing a map between the original id and
> the
> > > new
> > > > > > > > id in the d={} dictionary. Give it a try.
> >
> > > > > > > > You can also import_to_csv_field and export_from_csv_file an
> > > entire
> > > > > db
> > > > > > > > (as opposed to an individual table) and the remapping of the
> ids
> > > is
> > > > > > > > the default behaviour.
> >
> > > > > > > > Massimo
> >
> > > > > > > > On Mar 7, 1:31 pm, Joe Barnhart <joe.barnh...@gmail.com>
> wrote:
> > > > > > > > > Well, what if I wanted to restore a database with ids used
> in
> > > > > multi-
> > > > > > > > > table links? From what I read of the "import csv" it
> discards
> > > the
> > > > > id
> > > > > > > > > field and inserts new records -- which will cause any
> linked
> > > > > records
> > > > > > > > > from other tables to break. Come to think of it, I'm not
> sure
> > > how
> > > > > you
> > > > > > > > > restore a database at all unless the ids can be set
> explicitly.
> >
> > > > > > > > > At least this is one use case.
> >
> > > > > > > > > -- Joe B.
> >
> > > > > > > > > On Mar 5, 9:49 pm, mdipierro <mdipie...@cs.depaul.edu>
> wrote:
> >
> > > > > > > > > > Why would anybody do such a thing? This can break the
> > > integrity
> > > > > of the
> > > > > > > > > > database.
> > > > > > > > > <
> > > > > > > > > > Massimo
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"web2py Web Framework" group.
To post to this group, send email to web2py@googlegroups.com
To unsubscribe from this group, send email to
web2py+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/web2py?hl=en
-~----------~----~----~----~------~----~------~--~---
