--- a/dataimport.py	Thu Apr 25 16:10:56 2013 +0200
+++ b/dataimport.py	Thu Apr 25 17:30:09 2013 +0200
@@ -70,6 +70,7 @@
 import sys
 import threading
 import traceback
+import warnings
 import cPickle
 import os.path as osp
 import inspect
@@ -431,14 +432,16 @@
         # If an error is raised, do not continue.
         formatted_row = []
         for col in columns:
-            if isinstance(row, dict):
-                value = row.get(col)
-            elif isinstance(row, (tuple, list)):
+            try:
                 value = row[col]
-            else:
-                raise ValueError("Input data of improper type: %s; "
-                                 "expected tuple, list or dict." 
-                                 % type(row).__name__)
+            except KeyError:
+                warnings.warn(u"Column %s is not accessible in row %s" 
+                              % (col, row), RuntimeWarning)
+                # XXX 'value' set to None so that the import does not end in 
+                # error. 
+                # Instead, the extra keys are set to NULL from the 
+                # database point of view.
+                value = None
             if value is None:
                 value = 'NULL'
             elif isinstance(value, (long, int, float)):

--- a/doc/tutorials/dataimport/data_import_tutorial.rst	Thu Apr 25 16:10:56 2013 +0200
+++ b/doc/tutorials/dataimport/data_import_tutorial.rst	Thu Apr 25 17:30:09 2013 +0200
@@ -302,16 +302,16 @@
    ``subjtype`` and holds the type of the subject entity. For the example considered here,
    this comes to having [#]_::
 
-        store.relate(person.eid(), 'lives_in', location.eid(), subjtype=person.dc_type())
+        store.relate(person.eid(), 'lives_in', location.eid(), subjtype=person.cw_etype)
 
    If ``subjtype`` is not specified, then the store tries to infer the type of the subject.
    However, this doesn't always work, e.g. when there are several possible subject types
    for a given relation type. 
 
-.. [#] The ``dc_type`` method of an entity defined via ``create_entity`` returns
+.. [#] The ``cw_etype`` attribute of an entity defined via ``create_entity`` holds
        the type of the entity just created. This only works for entities defined via
        the stores in the CubicWeb's ``dataimport`` module. In the example considered
-       here, ``person.dc_type()`` returns ``'Person'``.
+       here, ``person.cw_etype`` holds ``'Person'``.
     
    All the other stores but ``SQLGenObjectStore`` ignore the ``kwargs`` parameters.
 
@@ -509,7 +509,7 @@
      #. first, a table is created for each relation type, as in::
             
             ...
-            store.init_rtype_table(ent.dc_type(), rtype, extu.dc_type())
+            store.init_rtype_table(ent.cw_etype, rtype, extu.cw_etype)
             
         which comes down to lines such as::
             

--- a/doc/tutorials/dataimport/diseasome_import.py	Thu Apr 25 16:10:56 2013 +0200
+++ b/doc/tutorials/dataimport/diseasome_import.py	Thu Apr 25 17:30:09 2013 +0200
@@ -86,7 +86,7 @@
         ent = store.create_entity(etype, **entity)
         if not _is_of_class(store, 'MassiveObjectStore'):
             uri_to_eid[uri] = ent.eid
-            uri_to_etype[uri] = ent.dc_type()
+            uri_to_etype[uri] = ent.cw_etype
         else:
             uri_to_eid[uri] = uri
             uri_to_etype[uri] = etype