300 |
300 |
301 The keyword argument that is understood by ``SQLGenObjectStore`` is called |
301 The keyword argument that is understood by ``SQLGenObjectStore`` is called |
302 ``subjtype`` and holds the type of the subject entity. For the example considered here, |
302 ``subjtype`` and holds the type of the subject entity. For the example considered here, |
303 this comes to having [#]_:: |
303 this comes to having [#]_:: |
304 |
304 |
305 store.relate(person.eid(), 'lives_in', location.eid(), subjtype=person.dc_type()) |
305 store.relate(person.eid(), 'lives_in', location.eid(), subjtype=person.cw_etype) |
306 |
306 |
307 If ``subjtype`` is not specified, then the store tries to infer the type of the subject. |
307 If ``subjtype`` is not specified, then the store tries to infer the type of the subject. |
308 However, this doesn't always work, e.g. when there are several possible subject types |
308 However, this doesn't always work, e.g. when there are several possible subject types |
309 for a given relation type. |
309 for a given relation type. |
310 |
310 |
311 .. [#] The ``dc_type`` method of an entity defined via ``create_entity`` returns |
311 .. [#] The ``cw_etype`` attribute of an entity defined via ``create_entity`` holds |
312 the type of the entity just created. This only works for entities defined via |
312 the type of the entity just created. This only works for entities defined via |
313 the stores in the CubicWeb's ``dataimport`` module. In the example considered |
313 the stores in the CubicWeb's ``dataimport`` module. In the example considered |
314 here, ``person.dc_type()`` returns ``'Person'``. |
314 here, ``person.cw_etype`` holds ``'Person'``. |
315 |
315 |
316 All the other stores but ``SQLGenObjectStore`` ignore the ``kwargs`` parameters. |
316 All the other stores but ``SQLGenObjectStore`` ignore the ``kwargs`` parameters. |
317 |
317 |
318 #. ``flush()``, which allows us to perform the actual commit into the database, along |
318 #. ``flush()``, which allows us to perform the actual commit into the database, along |
319 with some cleanup operations. Ideally, this method should be called as often as |
319 with some cleanup operations. Ideally, this method should be called as often as |
507 the relations are created in three steps: |
507 the relations are created in three steps: |
508 |
508 |
509 #. first, a table is created for each relation type, as in:: |
509 #. first, a table is created for each relation type, as in:: |
510 |
510 |
511 ... |
511 ... |
512 store.init_rtype_table(ent.dc_type(), rtype, extu.dc_type()) |
512 store.init_rtype_table(ent.cw_etype, rtype, extu.cw_etype) |
513 |
513 |
514 which comes down to lines such as:: |
514 which comes down to lines such as:: |
515 |
515 |
516 store.init_rtype_table('Disease', 'associated_genes', 'Gene') |
516 store.init_rtype_table('Disease', 'associated_genes', 'Gene') |
517 store.init_rtype_table('Gene', 'gene_id', 'ExternalUri') |
517 store.init_rtype_table('Gene', 'gene_id', 'ExternalUri') |