Re: 32 to 64 database conversion problem

2011-10-02 Thread Alexander Burger 
Hi Henrik,

 I just tried to run vizreader (from scratch) with the 64bit version and I
 did not experience any problems (as opposed to with early versions of the
 64bit version).

Great. That's good news :)


 So I thought I should try and run with a complete converted 32 - 64bit
 database.
 ...
 [/opt/resources/rss-reader/convert.l:8] DB read: Success
 ?
 
 Good or not?

This doesn't look good :(

It is an I/O (read) error, despite the misleading error message. It
seems it tries to access a non-existing object, or out-of-range database
file.


The reason is hard to tell without a direct inspection of the DB. I
don't think it has to do with concrete E/R issues, because the
conversion 32-64 runs on a lower level, directly following the links
between objects, and observing only a few E/R rules heuristically.


Could it be that already the 32-bit DB was not consistent? I remember we
talked about several problems in the beginning. What happens if you run

   : (load lib/too.l)

   : (dbCheck)

on the 32-bit system? It should print diagnostics of the form

   1 4 (5282 . 5282)
   2 1 (18591 . 18591)
   3 1 (272 . 269)
   4 1 (28254 . 28254)
   5 1 (14243 . 8815)
   ...

iterating all DB files in the first column, followed by lines like

   {obj1} (1 . {obj2}) var +Cls {1}
   ...

for each index. If something looks wrong, a hard error (!? ..) is
issued, or a warning like (dbfCheck Class) for suspicious DB-models, or
(dangling {obj} ..) for missing indexes is printed.

Cheers,
- Alex
-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: 32 to 64 database conversion problem

2011-10-02 Thread Henrik Sarvell 
Unfortunately I managed to accidentally delete the local copy 32bit I had of
the DB after the conversion was finished :(

However, when I run it on the live database which the copy is an older
snapshot of I get this:

{2L} (302 . {P-D}) tag +ArticleTag {1}
{2L} (302 . {P-;}) article +ArticleTag {1}
{2L} (302 . {P-H}) user +ArticleTag {1}
{5} (306 . {N-4}) tag +Tag {1}
[vr_db_check.l:3] {N-4K} -- Bad sequence
? (show '{N-4K})
{N-4K} (NIL (haskell NIL . {8-2y}) (iPhone {N-23} . {8-u}) (ibm NIL .
{8-2F}) (im NIL . {8-2B}))
- {N-4K}
?

Could this be the culprit?


On Sun, Oct 2, 2011 at 3:21 PM, Alexander Burger a...@software-lab.dewrote:

 Hi Henrik,

  I just tried to run vizreader (from scratch) with the 64bit version and I
  did not experience any problems (as opposed to with early versions of the
  64bit version).

 Great. That's good news :)


  So I thought I should try and run with a complete converted 32 - 64bit
  database.
  ...
  [/opt/resources/rss-reader/convert.l:8] DB read: Success
  ?
 
  Good or not?

 This doesn't look good :(

 It is an I/O (read) error, despite the misleading error message. It
 seems it tries to access a non-existing object, or out-of-range database
 file.


 The reason is hard to tell without a direct inspection of the DB. I
 don't think it has to do with concrete E/R issues, because the
 conversion 32-64 runs on a lower level, directly following the links
 between objects, and observing only a few E/R rules heuristically.


 Could it be that already the 32-bit DB was not consistent? I remember we
 talked about several problems in the beginning. What happens if you run

   : (load lib/too.l)

   : (dbCheck)

 on the 32-bit system? It should print diagnostics of the form

   1 4 (5282 . 5282)
   2 1 (18591 . 18591)
   3 1 (272 . 269)
   4 1 (28254 . 28254)
   5 1 (14243 . 8815)
   ...

 iterating all DB files in the first column, followed by lines like

   {obj1} (1 . {obj2}) var +Cls {1}
   ...

 for each index. If something looks wrong, a hard error (!? ..) is
 issued, or a warning like (dbfCheck Class) for suspicious DB-models, or
 (dangling {obj} ..) for missing indexes is printed.

 Cheers,
 - Alex
 --
 UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: 32 to 64 database conversion problem

2011-10-02 Thread Alexander Burger 
On Sun, Oct 02, 2011 at 08:33:26PM +0700, Henrik Sarvell wrote:
 Unfortunately I managed to accidentally delete the local copy 32bit I had of
 the DB after the conversion was finished :(
 
 However, when I run it on the live database which the copy is an older
 snapshot of I get this:
 
 {2L} (302 . {P-D}) tag +ArticleTag {1}
 {2L} (302 . {P-;}) article +ArticleTag {1}
 {2L} (302 . {P-H}) user +ArticleTag {1}
 {5} (306 . {N-4}) tag +Tag {1}
 [vr_db_check.l:3] {N-4K} -- Bad sequence
 ? (show '{N-4K})
 {N-4K} (NIL (haskell NIL . {8-2y}) (iPhone {N-23} . {8-u}) (ibm NIL .
 {8-2F}) (im NIL . {8-2B}))
 - {N-4K}
 ?
 
 Could this be the culprit?

Indeed. This indicates that an DB index is out of order, for whatever
reason. Don't know how this could happen, perhaps by some non-synced
access. I haven't seen this error in the wild before, but it is issued
by 'chkTree'. It could be repaired by 'rebuild'.

If you can live with the newly set-up DB, it would be the easiest.

Cheers,
- Alex
-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: 32 to 64 database conversion problem

2011-10-02 Thread Alexander Burger 
Hi Henrik,

 I haven't done anything yet, all 64bit testing has been done locally to see
 first what happens.
 
 So I try and rebuild live then and we see what happens, I load with pool and
 then just call rebuild, is that it?

As I understood it, you started out with an empty DB on 64-bits, right?
So for that one no rebuilding is required.

If you want to port the old DB from 32-bits to 64-bits, you should first
try to rebuild the index which gave an error, then run 'dbCheck' again,
and only run the routines in lib/db32-64.l after everything looks
good.

Yes, 'rebuild' should be called in a single-user situation, after
calling 'pool' (or simply 'main' without 'go'). 'rebuild' does call
'commit' by itself, so changes will be immediately manifest.

Cheers,
- Alex
-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe