AltME groups: search

The R3 GUI is still in development. The database model hasn't even 
been designed yet. You can make wrappers for ODBC and MySQL if you 
want to write the extensions - Robert has already started doing so 
for SQLite. Once device extensions are supported, we can start to 
get to work on the database model.

why clients wants those shits ???? 

because they read that apache + php + mysql + ajax/css  was the top 
of  art .... yurk ...

(and yeah you will say to me but why you don't do your solution os-commerce 
like based in rebol ?)

hum the amount of  capabilities in a e-shop web site clients are 
used to see now in days  are big...

Stat tools,  catalog edition, shiping, card. And then the hosting 
solution simply doesn't know about rebol so if it's not apache/php/mysql 
or apache/java/mysql  you are fried unless you have full access to 
the hosting solution and you are able to install what ever you want....(cheyenne!/rebol/mysql-protocol 
etc...)

Hi, I can setup mediawiki (or any other) on my web site: http://www.moldibi.com
which is up for 7-8 years. Its hosted on hostgator. I have unlimited 
storage / MySQL DB / bandwidth etc.

But I only have 1 domain name. If it is ok I can create any number 
of subdomains like world.moldibi.com or red.moldibi.com and give 
you a FTP account if necessary.

this is very cool.. I hope I will be able to study a little what 
you did.. I was lately playing with creating a simple data storage. 
To learn more about things and because sqlite has some bad sides 
, and mysql is not appropriate for my particular usecase.

You can repost in Announce group ...
 Need to finish documentation first.
Is it still pure ram based?
 ... Yes, but with two important differences:


 1) Values are stored in a binary! (reducing RAM overhead by about 
 50%)

 2) Reading/Writing a table to disk is easier/faster (as data is already 
 in binary! ... no conversion required)


Think of RebDB v3 as not so much a "database system", but a module 
that adds a new datatype ... table! ... which can be easily acted 
upon like any other REBOL datatype.

old version contained transaction log

 ... all the higher-level stuff is gone. It's purely a Storage Manager 
 now that enables you to create higher-level DBMS systems.
A testament to R3 code?

 ... Definately. The new 'apply and 'assert words among others make 
 things so much easier.
I do not know if RebDB can be adapted to fit that bill

 ... it can. RebDB provides the building blocks for higher-level abstractions 
 (much like ISAM files were/are the building blocks for DBMS's such 
 as DB2 and MySQL).
I hope I will be able to study a little what you did.

 ... I'd wait for the documentation ... the code is highly optimized 
 and rather terse. Without the conceptual model it's rather hard to 
 grok at first glance.

You can implement SQL protocol with the knowledge of REBOL level 
stuff, plus e.g. extensions. For mySQL (socket based), you don't 
even need extensions. The only thing I can see is missing, is good 
enough docs ...

Have you EVER looked into mySQL, postgress or SQLite protocol sources? 
Becuase I did, I even helped to fix them. There is no single bit 
of REBOL VM, which would help me to understand or fix the protocol. 
Hence - I can see your post as typical pro-open-source rant :-)

As soon as we get device extensions, SQLite can be wrapped, as well 
as any other DB with native libraries with compatible licenses (meaning: 
not MySQL). MySQL could be worked on right now through TCP.

sqlab: rigth, let's make string handling MORE COMPLEX. we definitely 
need that. let's copy MySQL, shall we?

I'm about to build a user login system, but I would like to know 
if it's a good idea to make this a public project so others can follow 
and contribute? Would it be a good idea to include it in Cheyenne? 
I don't intend to use MySQL for it as the rest of my site isn't DB 
driven.


I've not done anything yet, so I also need to know, what Cheyenne 
can already do in this area, to avoid duplicating functionality. 
Can I completely rely on the session context, or are there crucial 
parts missing?

I have different app-inits, one loads mysql other sqlite, sets different 
session keys, loads app specific modules

Now that there's a framework inside the main Cheyenne process, I'm 
considering adding more UniServe based implemented protocols to Cheyenne, 
like HTTP, POP3, IMAP and MySQL. There are of course all async.

HTTP is the most advanced, I use it in several apps in production. 
POP3 is beta. IMAP has just a few lines of code. MySQL is alpha, 
but working.

I am using both, slicehost and linode since a year now.
very good virtualisation with both of them. flash, mysql 
very stable, even a big mysql-server with only 384mb ram 
is running fine. linode has a better control panel, 
slicehost feels a little faster.

there is also another candidate for virt-hosting. 
gandi, located in france if somebody likes europe :-)
scalable via virt-shares.

https://www.gandi.net/hosting

Does anyone have any example code on using either SQlite or MySQL 
with Cheyenne?

I'd gather that it's not much different from using the mysql-protocol.r 
script under normal circumstances.

Does mysql-protocol.r need to be called in each rsp page that you 
create? I see that Cheyenne has database configuaration properties 
in httpd.cfg is mysql-protocol.r already implemented in Cheyenne? 
Sorry for such basic questions but the documentation is fairly limited.

Thanks Henrik I'll study up more on app-init. It just appears that 
mysql-protocol.r is being loaded by cheyenne on startup because of 
the way database access gets defined in the cfg file.

In addition to Henrik's answers, database access can be used in two 
ways, either "manually", opening and closing connection yourself 
from a CGI or RSP script (READ mysql:// prefered in that case), or 
by relying on the RSP webapp API to manage persistent connections 
(see DO-SQL function in RSP API doc).


In both cases, you need to load mysql-protocol.r. The best place 
for that is in the config file in GLOBALS section, just add :

worker-libs [
    %<path-to-mysql-file>/mysql-protocol.r
]


Usually, I define a %libs/ sub-folder in Cheyenne's folder and store 
there all the libraries used by all my RSP or CGI scripts.

No AJAX calls, nor other tricks. It's very fast for several reasons 
:
- almost no images.

- no JS lib to load and no JS code to execute when page is loaded.
- server is far from being overloaded.

- MySQL backend is very fast for read accesses (MySQL has a very 
efficient caching system for queries).

- Cheyenne RSP engine *is* fast (RSP scripts are compiled to REBOL 
code and generated code is cached in memory)

MySQL has a very efficient caching system for queries

are you using mysql query cache?

are you using mysql query cache?
 It's transparent for the user, MySQL is caching by default.

Terry: I've never setup anything wrt caching in MySQL.

In the config file is worker-libs contained within globals or should 
it be preceding globals. Trying to get mysql working.

If you're referring to the httpd.cfg file, I don't have any references 
to mysql except for those referring to actual databases. What I did 
to test mysql was use the rebol mysql driver (in a normal rebol shell) 
outside of the Cheyenne environment to make sure it worked. Hope 
that helps.

I usually load mysql driver from a local Cheyenne libs/ sub-folder 
:

globals [
    ...
    worker-libs [
         %libs/mysql-protocol.r
    ]
    ...
]

James: it's not mandatory, you can load mysql driver from 'on-application-start 
event for example (but you'll need to do that for all your webapps). 
It's just simplier to declare it in config file once for all.

Good ... I guess ... I thought I had lost the ability to set a parameter. 
 If you are looking, I also had trouble with the worker-libs and 
had to enter absolute addresses to get them to work ... %/c/cheyenne/www/private/mysql-protocol.r

cheyenne does support mysql only? or can we use sqlite or sql server 
thru odbc?

In order to use the mysql protocol, you have to include it as a worker-lib, 
I guess.

Add %path/to/mysql-protocol.r to your WORKER-LIBS block in the %httpd.cfg, 
that should do the trick.

I tried it with mysql also, but the result was same. So it is not 
an odbc issue I guess.

I tried with cheyenne-r0919.exe binary version with mysql server 
on localhost, same error: 
** Access Error : Invalid port spec: mysql://[root-:-localhost]/test

mysql driver is not already in cheyenne?

no, you must download it here: http://softinnov.org/rebol/mysql.shtml

Don't use odbc - Cheyenne doesn't support it with the default build. 
Use the standalone mysql protocol linked above.

I see. I don't have SDK. Is there a license issue about mysql/odbc 
drivers or do you have a plan to put in next releases?

Don't mix the ODBC- with the mySQL-driver. Doc's mySQL-protocol works 
with all versions of Rebol(2). You use it thru the mysql://-scheme.

ODBC drivers are binary, and are only included if you have /Command 
or the SDK. Which also include a mysql driver, but not as good a 
driver as the free one linked above.

It would be great if the drivers (mysql/sqlite/odbc/postgre) included 
in cheyenne. Ofcourse external dependencies is not good for Cheyenne, 
but optional driver-included binaries would be good anyway.

what does Database C drivers: MySQL 3,Oracle 8 ... mean, btw?
it doesnt work with mysql 5 and ora 10?

Those drivers are built in REBOL/Command. It depends if Mysql 5 and 
Oracle 10 servers are compatible with older drivers. I can only answer 
for Mysql, and the answer is no.

Not everybody run on Mysql 5 and Oracle 10, so it can be useful to 
some users. Also it's all or nothing, I cannot chose which native 
feature I want to include or not.

When any process wants to write, it must lock the entire database 
file for the duration of its update


However, client/server database engines (such as PostgreSQL, MySQL, 
or Oracle) usually support a higher level of concurrency and allow 
multiple processes to be writing to the same database at the same 
time. This is possible in a client/server database because there 
is always a single well-controlled server process available to coordinate 
access. If your application has a need for a lot of concurrency, 
then you should consider using a client/server database.

My test was on R2, may be would be different on R3.
I'm mostly agree with Gregg.

This line is in do-sql/flat function (if you use R2 native drivers, 
not in Softinnov's mysql driver) so if your resultset has millions 
of rows you gain 3-4 seconds on a slow machine.

I can't see why they  wouldn't ...as that means they can offer pretty 
much the whole stack ....  OpenSolaris, Mysql, Apache, PHP

full ack BC, graham if you need (like) zfs try freebsd, it's already 
there. 
better perfomance, cleaner handling and much faster than linux. 

if you need a wm try xfce or lxde. feels like running win 3.11 on 
a quadcore.


for rdbms look also at monetdb, in nearly all cases 5-10 times faster 
than mysql.

very advanced designed dbserver and a nice abstracted query layer 
for sql and xquery. 

if you need a good allrounder/workhorse try postgresql (scales good 
on multicore)

free- or netbsd is a solid base for this. (but only until a real 
smp ready microkernel
os like minix is finished :-)

graham I am using a 'prototype multi cli connector' for different 
databases.

(currently mysql/postgresql/monetdb/sqlite. more are in progress) 
I will provide you

with a source link in a couple of days if you like. I would never 
ever use odbc, it's to unstable

and makes always problems when the db load is highest. but ok I also 
don't like synthetical 

benchmarks or theoretical feature lists. real life experiences are 
best...

like this?
the cli connector is using the cli component nearly all major
databases delivering. the connection is made via rebols 

call/wait/info/output/error and a simple parse after, for the resultset.
I am using this prototype mainly for a q & d connect

to mysql/postgresql/monetdb/sqlite. on my list are also connectors 
for

firebird/oracle/greenplum/sybase/ingres/infobright/frontbase and 
cassandra.
pros:

1. very fast for single requests
2. no rewrite of code needed if a new version or protocol is out
3. easy 'data migration' between the db's

4. adding new db's are a matter of hours only (see the cli spec thats 
all)
5. fast prototyping and testing for new db's

6. robust, never had any trouble with cli's even with bigger resultsets

7. should be perfect also for traditional cgi (the process starting 
overhead is minimal, execpt you name is facebook)

8. very small footprint (~120 lines for connecting to 4 db's, could 
be the half)

with a nice tcp-server component like rebservice the 
cli multi connector could be very usefull as a c/s connector.
I made a test with 2.000 concurrent calls (simple select) 
on a 4 gig quadcore. the cpu was only close to 50%, a good value.

cons:


1. slow if you have very much serial inserts (unless you shape them 
into one sql query)
2. need to start a cli process for every request
3. needs a tcp server for non-local connections
4. some more, but who cares ;-)

with a solution to keep the cli open from rebservice,

these cons could disappear and the speed diff overhead to a memory 
based lib
could be marginal.

pekr, can't confirm this (under linux where I am using this connector). 

a standard hot wildcard query (select * from db limit 1000) takes 
in average 320 ms 

with cli and 560 ms with docs cool mysql driver which I am using 
daily. 

I think it looks different if you compare e.g cli against sqlite, 
connected via native 

lib access but all connectors working via tcp shouldn't be faster 
then cli I guess. 
but please don't nail me with these numbers.

this cli connector is currently a prototype idea with some nice potential 
at this

moment nothing more, at least it works very smooth for migration 
tasks.

the best is if you make your own tests and see if its usefull for 
your demands.

there are 3 extension which would be very cool. 

1. tcp server for easy remote request  without the need for the cli 
on the client side (e.g. rebservice)  

2. a smart sql-syntax mapper for interactive migration (you can't 
read e.g. a mysql dump directly into postgresql) 

3. a stable cli alive holder to eliminate the startup payload for 
the request.

Doc, yes,  I realized that it was representative of an error after 
trying to create a test page to read a mysql db using your mysql 
library (just to test my mysql install). I wsa wondering though whether 
it's true that all the scripts have to be located within the root-dir? 
 That is, in my case, I had the curecode folder on a different drive.adn 
referenced that via the "root-dir" in the curecode web-app section. 
Well, actually, that was generated bu the "install.r" script. Just 
curious.
Thanks.

Guys, thanks for your input. I did log off, thinking that perhaps 
not doing so might be causing the issue. This morning, the same "page 
unavailable" occured. I checked the log and there is an RSP script 
 error in the head.rsp file:

 ** Script Error : say expected data argument of type: string none 
	** Where: rsp-script 
	** Near:  [projects/2: say projects/2 

Then a separate entry 

Request = make object! [ ...
 referring to the index.rsp file.


I can in fact run my test page which has a mysql test  that reads 
the curecode tables within it without any issues.


I have that work-around of restarting the service so I'm cool. I 
was just wondering if anyone else had that same behavior.

I'm also going to test it from another machine today.


Interesting. Reaching the server from another machine worked. Then 
when I went back to the server machine and tried curecode, it also 
worked.  

I'll do some more tests and let you know. Thanks.

Doc, it says in the trace.log that there is an SQL error:


** User Error : ERROR 1064 : You have an error in your SQL syntax; 
check the manual that corresponds to your MySQL server version for 
the right syntax to use near '' at line 6 
	** Where: none 
	** Near:  [do-sql/flat 'r3bugs [{

It should be something like this:

mysql://user:[pass-:-localhost]/bugs


I also tried it in a different console and it only appears if the 
mysql-protocol is not loaded.

There is no reference to mysql-protocol.r anywhere in the source 
code. Could that be it?

In 0.9.8 there is a reference to mysql-protocol.r in app-init.r, 
but it's gone in 0.9.12.

Ah probably, now CureCode expects that the %mysql-protocol.r be loaded 
externally. The best way to do that is to instruct Cheyenne to load 
it directly by declaring it in the GLOBALS section of the config 
file, like this:

	worker-libs [
		%<path-to-mysql-protocol-folder>/mysql-protocol.r
	]

I have upgraded the install script in v0.9.12 archive to handle the 
mysql-protocol.r installation.

here's a better example  

dataset: [ "subject" "predicate" "value" "bob" "fname" "Bob" "bob" 
"age" "42" "Maxim" "age" "unknown" ... ]
so the triple is subject, predicate value  

with the ability to say quickly return   every triple  where "predicate" 
(the second part of the triple)  = "age"


i'm doing this now with MySQL as a triple store, but series should 
be much faster

That's not bloat of code, but bloat of functionality I tam talking 
about. My experience is as follows - sometimes I like to use frameworks, 
but I don't like using frameworks just for the sake of frameworks 
themselves. Young guys did new SW for our old kiosks we installed 
around, and it seems so complicated (all xamp, web, replicated mysql), 
that they had to call their guru to set-it up.

Robert, It's interesting the tradeoff these days between a DB and 
loading REBOL data files.  For example, the MySQL that runs the wiki 
on REBOL.net consumes 130MB of main memory on that machine!

I use firebird and it's only less than 1Mb .. so why is mysql consuming 
130mb ?

If you're not using innodb, you should switch it off by uncommenting 
skip-innodb in /etc/mysql/my.cnf (default place for the config file). 
This will save you ~70MB. For the remaining 49MB, I don't know, I 
guess that a good part of that is used by caches.

By that I mean it was untolerable slow on some VPS where I assume 
same disc was used for streaming media, update was taking seconds 
while I could on the same system open a 1M rebol data file change 
it and save it back in almost no time. I couldn't get it why this 
is happening, and this was at neglegibly small database. I moved 
whole app that uses sqlite to some vps where it's almost alone on 
whole server because of this. And at Site Assistant where I used 
sqlite only for "mailbox" for bots (to send them work) I had to switch 
to mysql for this (it was the same server that blocked this heavily)

Graham: I was replying to discussion above about the need to move 
R3 chat to DB like SQLite or MySQL versus REBOL data files

a R3 ODBC scheme and others (mysql etc...)

Is Doc's MySQL driver working in R3? Has anyone tried to get it up 
& running?

GUI, console (not willing to experiment that much with the Windows 
default one), call, protocols (ftp, email, easy-cgi), DB (mysql, 
sqlite)

Henrik, kust for curiosity. Which database connectivity ?PostgreSQL, 
MySQL ?

I presume Linux users will want a native mysql driver

We could as well use the group power-pack, although it was meant 
a bit differently - to create package of most usefull add-on stuff, 
so e.g. mysql protocol, rugby, uniserve, etc.

From the loading modules doc: "...if a version number appears before 
any module name, it is assumed to be the REBOL system version.

  Needs: [3.0.2 mysql 2.3.0 http-server 1.0.1]

 Is there an explicit alternative? And how would you specify that 
 you need View or Command rather than Core?

And for checksums, would 
 it make sense to allow a keyword before the checksum, so you could 
 choose md5, sha1, or something else in the future? An unmarked binary 
 could still be sha1. I know it maps to the /check refinement on IMPORT 
 as well. I'm just thinking of implicit meaning versus long lifecycles.

BrianH - from end user's perspective, you might not be right - missing 
pop, smtp, ftp, sqlite, mysql, postgress in official distro, just 
to name the few, GUI's not useable yet too, hence ppl keep tied to 
R2 ....

Gentlemen, thank you. I will study your methods. It is just one level 
and it was to handle indexes I was receiving from a mysql db that 
were returned as [ [1] [2][ 3]]. Again thank you. You guys sure know 
your stuff!

I am trying more Red examples from Kaj's bindings.  Some working 
well.... but GTK failing on libgio-2.0-0.dll   Other DLLs that were 
needed for WinXP seemed to be in the mysql distribution ... except 
this one.     Little hits on reliable downloads of pre-built DLL. 
  Anybody used it in WinXP?