Re: [Modeling-users] Foreign Keys

[Sebastien B. <sbi...@us...>]

Was this meaningful, or do you still think you need to be able to
provide your own PKs?


Sebastien Bigaret <sbi...@us...> wrote:

> Okay, so:
>=20
>   1. when you're saving the db into xml, you want to avoid saving objects=
 in
>      relations (I presume that's why 'i18n' e.g. is hard-coded),
>=20
>   2. when restoring, you have to find back the objects in relations.
>=20
> About 1: I saw you're using CustomObject.snapshot(). Note that since
> fetchRawRow() exists, you also have a method CustomObject.snapshot_raw()
> at hand which returns the row corresponding to the object (and this one
> is exactly the same one than the one you'd get with fetch and parameter
> rawRows=3D1). So, as expected, you get the PK and the FKs defined for the
> corresp. entity, *no matter* whether they are class properties or not.
>=20
>   (And yes, it should be documented :)
>=20
>   Now for restoring, I must be possible to do something like this:
>=20
>   - initialize and populate each object, store them in a dictionary with
>     something like=20
>=20
>        rootEntityName=3Dentity.rootEntity().name() #this makes it easier
>                                                  #if you use inheritance
>        d[rootEntityName+'_%i'%pk]=3Dobject
>=20
>   - then iterate on your objects and fill the relations, just as you do,
>     except that you'll avoid the slow xpath query. Instead, you'll
>     iterate on your i18ns and find the corresponding master object with
>     a simple lookup in the dictionary, because the master will be:
>=20
>       rootEntityName_master=3D...
>       master=3Dd[rootEntityName_master+'_%i'%i18n._fk_master]
>=20
>     given that the fk is stored in the i18n._fk_master
>=20
> > So skiping PKs would be much more simple
>=20
>   In fact, your problem here is not exactly to set a PK you generate
>   yourself, but to match an object's FK w/ an other object's PK, which
>   is not exactly the same pb. and cannot be easily solved.
>=20
> > but having the framework
> > doing the dump and restoration would be even beter.  I do the dump
> > like this (phpMyAdmin is full Latin-1) :
>=20
>   In fact, yes, this would be better, for example with serialization of
>   EditingContext. Not done however...
>=20
> Last, I don't know why you insist on dumping/restoring your db w/ the
> framework, but that's not the most efficient way of doing this, is it?-)
>=20
> Maybe you should consider dumping and restoring raw sql (postgresql can
> dump a whole database in a text file). In this case, the only thing
> you'll have to take care of wrt the framework is that sequences
> supporting PK generation (you're using postgresql, right?) get the right
> value before trying to insert new objects (the sequence should start at
> max(id)+1 for a given table, or, if you're using inheritance, to the
> max(id) of the different tables involved in an inheritance tree --there
> is one and only one sequence used for generating the pks per root
> entity).
>=20
>=20
> -- S=E9bastien.