QSF Import of gncCustomer and gncAddress Issues (and partial success)

[Derek Atkins]

Georgi Mirchev <manager at mirchevideas.com> writes:

> There are several variants:
> 1. The gncCustomer should not autocreate two gncAddress objects.

This doesn't work.  The gncCustomer needs the addresses.

> 2. The destroying object deregisters itself from the book it is (do we 
> know for each object which book it resides? can one gncAdress live in 
> more than one book?)

This would work.   (yes and no, respectively)

> 3. The code that calls the destructors should remove the object from the 
> book. There might be a problem, since we are not sure if we should 
> remove the object from the book first, or destroy the object first. This 
> is in case the removing from the book requires more than a pointer, or 
> the destructor assumes the object is in the book.
>
> And maybe the solution is 1. plus one of 2. or 3. Please advise.

Nope.  1 is always wrong, because LOTS of code assumes that a newly
created Customer object has the address.  In reality, the Address
SHOULD NOT be a first class object.  The ONLY reason I made it its own
GNC object (it was NOT originally a QOF object) was to abstract the
fact that Customers, Vendors, and Employees all had addresses, so I
wanted to reuse the code across them all.

The overarching objects (customer, vendor, employee) all depend on
the underlying address.  It's only QSF that assumes you can "set"
an address.... Which IMNSHO is a broken and stupid assumption.  So
it's QSF that should get fixed, not the GNC object.

> Since the QSF Import/Export is disabled in the head, how to reenable it 
> for testing?

Revert the patch that disabled it.

> Regards,
> Georgi

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord at MIT.EDU                        PGP key available