World: r3wp

A colleague of mine showed me an Object Relational Mapping product 
that generates a series of DLL for .net. (Abstracts the database 
tables as objects with methods for inserts, updates, deletes, joins, 
etc..) I don't know if I am a fan of such a tool but I was wondering 
if anyone is doing something similar with rebol or if this type of 
functionality is built in Cheyenne. Is it possible to provide abstraction 
of the databases in Cheyenne using a series of RSP's, web services, 
ORM technology? What's the best approach for enterprise portal development 
with Rebol?

Hm, I have a very small data abstraction library that uses a prototype 
for a database, currently file-based - but it's not very ENTERPRISE 
:-)

Kaj can you describe the benefit. I have seen a few sites that are 
for ORM and others against.

Oh, one of the aspects of my library that make it not enterprise 
is that I'm not doing object-relational mappings. :-) I'm staying 
away from both as much as possible

They're both technologies with too much overhead, and mapping one 
to the other makes it worse

In general, every time you have to glue different technologies together 
you have an impedance mismatch, so if it can be avoided it's worth 
it

Abstracting data access is useful in many cases, though. For one 
thing, you could switch between a light-weight, native REBOL implementation 
and a heavier implementation using some other technology such as 
a relational or object-relational database

I'm using one REBOL prototype object for every database, because 
it allows to store state

For example, I could use that to implement caching in the database 
object later, or have different implementations optimised for different 
uses, without changing the applications that access the data

That's the principle behind RoughCut too, using ports as the abstraction 
layer...

I haven't looked into that yet; I should someday

How big is RoughCut?

240~ lines not including QM core dependencies.

That's rather similar to mine, but there's a lot it doesn't do yet

RC is ultimately limited by the Active Record pattern though.

Which maps table -> port, record -> object.

Charles, sounds like your pick if you want an object interface to 
your database :-)

I WIll look into it.  Now the question I am trying to come to grips 
with the whole abstraction of tables vs hiting services to query 
the database directly and return the data. Anyone care to weigh in?

do you mean n-tier?

it depends alot on your database schema  if you have a very straight 
forward simple schema  ORM will save you from the ravages of sql 
should you need such saving

if you dont  if you have natural keys or need unions or othe ..."advanced" 
sql  (as if there were such a thing) you will likely need to hand 
tweak the mappings anyway

N-Tier I get. Presnetation layer, App Logic, Database Layer. This 
ORM is another layer between the app logic and database and was wondering 
if you lose flexibility and performance. Is the real gain in crud 
style applications because I don't think I would want another layer 
in a BI/Reporting application.

I'm trying to serve JPGs through an RSP Page.  The following is the 
entire contents of the RSP Page:

<% 
	do %init.r

 results: SQL rejoin [{SELECT data FROM images WHERE id="#^{} select 
 request/content 'id {^}"}]
	unless empty? results [
		img: first first results
		response/reset
		response/set-header 'Content-Type "image/jpg"
		prin img
		response/end
	]
	print "FAIL!!!!"
%>


This seems to almost work. But I have to load the result twice in 
REBOL to actually get the image.


view layout [image load load http://localhost/image.rsp?id=375A5EDB9102ECB08B3A185186650D3C]


Displays the image.  The value returned from the Database is Binary! 
so it should be the same as read/binary as shown in the example of 
how to do this in the Cheyenne docs, shouldn't it?

Any ideas?

I simplified the RSP Page to:

<% 
	response/set-header 'Content-Type "image/png"
	prin read/binary %temp.png
	response/end
%>


and now the browser says, "The image 'http://localhost/png.rsp'cannot 
be displayed, because it contains errors" but the previous example 
of LOADing the url twice displays the image correctly in REBOL.  
There must be another content header I need to set...  Researching...

WOOT!   Solved.


In the Response/Reset  example in the docs you use PRIN to output 
the image data, but in the Response/Buffer example you use RESPONSE/BUFFER 
to send the image data.  

<% 
	response/set-header 'Content-Type "image/png"
	response/buffer: read/binary %temp.png
	response/end
%>

Works.

You're right, that's an error in the example code, PRIN cannot work 
here because it will output the binary! in its molded form (with 
#{...}) and not only the raw data. Setting directly the buffer is 
the right way to send binary data (and RESET is not required in that 
case).


Online documentation fixed (RESET example changed to output a text 
content instead of binary).

Thanks!

For some reason Cheyenne is eating up GBs of RAM.  Once it crashed 
saying something about not enough memory (it was using 900+ MB)  
I restarted the server and it works fine except that I have seen 
it use up to 1.5GBs of RAM.  Windows Task Manager (on Vista) baseline 
RAM usage is 500MB, however, after I killed the process using 1.5GB 
Task Manager claims that only 300MB of RAM is used but it still says 
that 1.5GB of RAM is cached and says I have 7MB RAM free.  I have 
2GB physical RAM.   The problem may also be Ashley's SQLlite driver 
as I am using that to manage some images.

I've never seen Cheyenne do this.

I think I know what the problem is but I haven't had a chance to 
test it.   The SQLlite driver does an automated LOAD of datasets 
pulled from the DB.  REBOL has known memory leak(s) when handling 
lots of images.  I'm storing the binary value of images in the DB. 
 Thus when I pull the images out of the DB then the driver is LOADing 
them.  When I get a chance tonight I'll test this theory.

Hrm...  The script wasn't loading the image where I thought it was. 
The data was actually Binary!  not Image!  so I'll have to do some 
more digging...

I saw such issue in Cheyenne a few times with an older REBOL version 
(2.5.xx) and it was caused by a REBOL GC bug. Never saw such behaviour 
since then.

I'm using the encapped version...

Heh...  A more effecient design goes a long way.  I've minimized 
requests to the server and dropped the memory usage by about 75%


Speaking of minimized requests...  Has anyone done any AJAX/JSON 
stuff with Cheyenne?

Yes

Can you elaborate or point me to something somewhere that demonstrates 
how you did it?  I'm being lazy and I don't want to figure it out 
on my own. ;-)

Ask Terry ... he has he says.

I also installed the yahoo javascript libraries ... and they're using 
Ajax ... and it's all being served by cheyenne

Ajax is just javascript making an asyn http call

I know what AJAX is.  ;-)  I've used it many times, I've just never 
set up the server side before.  I am planning on using the json.r 
script from the Library...  I'll just play with it and see what I 
come up with...

Strange...  


I added some working JSON...  Somehow the .rsp file handling the 
JSON request is using functions that aren't including in the rsp 
file.  Is it supposed to do that?

Do you have an example?

I have tag.r that has 

tag: context [add: does [something]]


I DO tag.r on most of my RSP pages but not on json.rsp yet I'm using 
TAG/ADD in json.rsp without problems.

Sounds like it is being set globally?

tag is being set globally but I didn't expect includes to be persistent 
across different pages.

Having your TAG word already defined is a side-effect of persistent 
RSP processes. You should *NEVER* rely on it, because your script 
can be executed within a different process where the word may not 
have been defined.

Btw, if your %tag.r script is required in most of your RSP scripts, 
just DO it once in 'on-session-start (in %app-init.r).

btw, love the new website  :-)

feature request: add on-global-page-start and on-global-page-end, 
same as on-page-start and on-page-end but executed for all rsp pages, 
not only for webapps

Maxim: thanks, it still needs a lot of work to be completed : integration 
of a CureCode instance for bug tracking, writing lot of documentations,...