Database Code Challenge(s)

[John]

I'm going to let Alysson chew on this for awhile before I refine the concept any further.

Required Format?

[jalih]

All well and good, but you need to get the data from the file first. So how would you approach that?

Too bad using JSON for data is not allowed. I would have used 8th for this challenge. I think JSON is readable enough and if needed nicely formatted presentation of the data needs just a few lines of code.

In 8th, only few lines of code is needed to read JSON data from file to map. Following code reads data from the file and outputs keys and data from the resulting map:

Code: [Select]

"db.json" f:slurp json>
( swap "%s : %s" s:strfmt . cr ) m:each drop


[AIR]

I'm going to let Alysson chew on this for awhile before I refine the concept any further.

Required Format?

The primary requirement is that the textual data must be kept entirely in human-readable digital format (i.e. text files), thus, software-proofing the data. That includes indices and data (images and other media excepted). The artefact record is, in fact, a single document. Even EXIF-type metadata on media files is maintained in separate text documents alongside the media files.

[John]

The associative array definitions in a text file aren't readable? The web site definitions and 'meta data' can reside in the included template file. All run by the pre-processor threaded.

[AIR]

The associative array definitions in a text file aren't readable?

Have you looked at the sample data file Alysson posted?  She also requested that when printed the files should look like a report, no matter what was used to do the printing.

[AIR]

Too bad using JSON for data is not allowed. I would have used 8th for this challenge. I think JSON is readable enough and if needed nicely formatted presentation of the data needs just a few lines of code.

In 8th, only few lines of code is needed to read JSON data from file to map. Following code reads data from the file and outputs keys and data from the resulting map:

Code: [Select]

"db.json" f:slurp json>
( swap "%s : %s" s:strfmt . cr ) m:each drop


I'm curious to see what you mean.  I've attached a json version of the yaml data file I used....

AIR.

[John]

The question becomes is the goal to maintain a broken design or make it run under today's standards?

[AIR]

The question becomes is the goal to maintain a broken design or make it run under today's standards?

The question is can the code challenge be met as originally presented.

I personally don't have an issue with the design, as you put it.  When I saw the format of the data file, it immediately made me think of yaml formatted files.  I'd just never seen yaml used to do what Alysson is doing.  So where you see something as broken, I see someone pushing the envelop.... 

[AIR]

The associative array definitions in a text file aren't readable? The web site definitions and 'meta data' can reside in the included template file. All run by the pre-processor threaded.

You added the second sentence while I was posting a reply.

All I can say is:  show me....

[John]

I m still in concept definition mode and coding will come when I see an example of something working and Alysson smiling.

[AlyssonR]

That's why I didn't go for associative arrays - the data is intrinsically too flexible for most approaches ... to the point of being positively limp. (I think I may use that expression in the documentation  )

What I have actually done is to serialise everything with no expectations as to meaning whatsoever; any meanings are drawn from the index schema and will, at some point, include logic to utilise a field value as a link to a file (probably by using a property such as .link [file path] )


As to background processes, a lot of the  routine maintenance tasks  will, hopefully, be attended to using SB long before I get around to converting the program logic.

I find myself really mourning the lack of Type (or other data structure) definitions in SB (or have I missed something here??)

[John]

I find myself really mourning the lack of Type (or other data structure) definitions in SB (or have I missed something here??)

SB supports LONG, REAL, (binary) STRING, ARRAY and UNDEF. Arrays can be index or associative or a combination of both with no practical limitation. A great way to build complex structures.

You can pass an UNDEF variable as an argument to a function/sub and return a complex array structure in the same variable name.

[jalih]

I'm curious to see what you mean.  I've attached a json version of the yaml data file I used....

Here is some demo code to read JSON file into map and display the content on screen...

Code: [Select]

var db


: load
  "testI.json" f:slurp json> db ! ;


: number-or-string
  . cr ;


defer: iter


: array
  cr ( nip space space space space dup >kind iter cr ) a:each drop ;


: map
  cr ( swap space space . ": " . dup >kind iter ) m:each drop ;


: iterator
  [ ' number-or-string , ' noop , ' noop , ' number-or-string , ' array , ' map ]  swap
  caseof ;


' iterator w:is iter


: disp
  db @ ( swap . ": " . dup >kind iterator ) m:each drop ;


load disp
bye


[AlyssonR]

I find myself really mourning the lack of Type (or other data structure) definitions in SB (or have I missed something here??)

SB supports LONG, REAL, (binary) STRING, ARRAY and UNDEF. Arrays can be index or associative or a combination of both with no practical limitation. A great way to build complex structures.

You can pass an UNDEF variable as an argument to a function/sub and return a complex array structure in the same variable name.

I suppose arrays of arrays of arrays of arrays would do it

Use an associative array for the sub property classes ....

I'll sleep on it.


I'll have a play when I have time.

[John]

Any arrary (matrix) segment can be assigned to a new array or a element of itself. Structures on steroids.