Menu
▾
▴
Re: [Rexxtill-devel] Architecture - supporting multiple databases
|
From: Ven & C. I. <vi...@bi...> - 2011-03-21 23:30:38
|
I'm with Jon on this one.... let's not complicate it further by adding one more layer of software than necessary as this would mean we'd have to install BSF4Rexx and JDK (Rony would probably disagree) although Bob has a point in that all the databases have got JDBC interfaces.
Regards,
Ven
----- Original Message -----
From: Sahananda (Jon) Wolfers
To: rex...@li...
Sent: Tuesday, March 22, 2011 9:26 AM
Subject: Re: [Rexxtill-devel] Architecture - supporting multiple databases
You're joking ... right?
On 21 March 2011 22:07, Robert Hamilton <bob...@gm...> wrote:
I guess what I'm saying is: let's use JAVA where ever we can to Engineer this Product....
BOBH
RICHARDSON, TEXAS USA
On Mon, Mar 21, 2011 at 4:59 PM, Sahananda (Jon) Wolfers <sah...@wi...> wrote:
Hi Bob,
I'm not sure I understand what you're suggesting.
I know that Java does give you the JDBC which allows you to connect to many different databases (this is what openBravo uses. I installed openBravo and it came with Apache Derby as the default dbms. Changing it over to MySQL was remarkably easy. I was impressed that far).
The JDBC would be the equivalent of the DMO in my thread below, but one still has the 'problem' of the different underlying dialects.
If one wanted to use JDBC with ooRexx (and if we suport multiple databases JDBC seems likely to be the way to do it) then I would imagine using BSF4ooRexx to do it.
I hope I haven't completely misunderstood you
Jon
On 21 March 2011 21:35, Robert Hamilton <bob...@gm...> wrote:
This concern might need to be a sub-thread in this deal. One thought == JAVA surely has developed ways to deal with different manifestations of DATA. Net Rexx deals with Java. Could there be a way to Massage the Data problem with NetRexx?
BOB H
Richardson, Texas, USA
On Mon, Mar 21, 2011 at 4:09 PM, Sahananda (Jon) Wolfers <sah...@wi...> wrote:
In the further thoughts on licenses thread I said
As far as database goes, I like the idea that we design the project so that one can sit it on a database of one's choice, but I think it's ok to start out with just one offering.
I've been sitting on trains a lot again today, and I was wondering how we designed it so that we sit on one database now, but can later swap in others. It seemed like such a daunting task that I thought we'd probably quietly never get around to it, when I had a bit of an epiphany.
I had been troubled by the differing syntaxes of various SQLs and trying to work my way around that, when a different way of looking at the whole problem came to me. I don't know if this is new thinking, this may be the way that it's always done in large oo developments, or it might be something that's been tried and failed or just too daft to contemplate.
I don't know the correct terminology, so bear with me while I try to describe it.
I have a wrapper (based on something Lee Peedin wrote) around rexxsql that allows me to query MySQL and get results back etc., and I tend to think of that as the database manager object (let's call it DMO). I had been thinking that if we supported many different rdbmss we'd need several of these DMOs, one for each database, but that leads to problems, because of the different sql dialects. Of course, you can stick to just the core of sql, but there are lots of things that I'd want to do that I have no idea how to do without the sql extensions.
Then I thought about the MVC approach to the GUI and how what we needed to do was to define a set of queries that we would need to pass and build a wrapper around the DMO to handle the different dialects.
Then it occured to me that what we REALLY should do is wrap the DMO in an object-database object (lets call it ODO for short).
ODO would understand the structure of the various objects we design and the database's table structure.
When one instantiates an object, you pass it the key fields, and then it passes itself to ODO and tells ODO to populate it. When it needs saving, again it passes itself to ODO and ODO saves the data in the respective tables.
Say for instance we have a keyboard-layout object. When you instantiate it you pass it the parameters it needs to define itself (keyboard name, Region & Group are what I had in mind) it toddles off to ODO and ODO populates it with the details of the individual keys (the names of the files containing the pictures for the keycaps, the actions taken when the key is pressed, where they are arranges on the screen etc.)
Or a product, you type product~new('1234567890123'), and the init method passes it to ODO who finds that barcode or product code in the database and fills in the description, price, stock position, tax code etc. (would you believe it, my ordering system product objects have 79 attributes - I don't think we'll need anything like that for the till))
So, to add support for another database we would just need to provide a new DMO and an ODO that was tailored for it. The task is finite, because it is limited to the objects we define.
Anyway, what do people think? Might this be the way to go? Interested to hear your thoughts,
Jon
------------------------------------------------------------------------------
Enable your software for Intel(R) Active Management Technology to meet the
growing manageability and security demands of your customers. Businesses
are taking advantage of Intel(R) vPro (TM) technology - will your software
be a part of the solution? Download the Intel(R) Manageability Checker
today! http://p.sf.net/sfu/intel-dev2devmar
_______________________________________________
Rexxtill-devel mailing list
Rex...@li...
https://lists.sourceforge.net/lists/listinfo/rexxtill-devel
------------------------------------------------------------------------------
Enable your software for Intel(R) Active Management Technology to meet the
growing manageability and security demands of your customers. Businesses
are taking advantage of Intel(R) vPro (TM) technology - will your software
be a part of the solution? Download the Intel(R) Manageability Checker
today! http://p.sf.net/sfu/intel-dev2devmar
_______________________________________________
Rexxtill-devel mailing list
Rex...@li...
https://lists.sourceforge.net/lists/listinfo/rexxtill-devel
------------------------------------------------------------------------------
Enable your software for Intel(R) Active Management Technology to meet the
growing manageability and security demands of your customers. Businesses
are taking advantage of Intel(R) vPro (TM) technology - will your software
be a part of the solution? Download the Intel(R) Manageability Checker
today! http://p.sf.net/sfu/intel-dev2devmar
_______________________________________________
Rexxtill-devel mailing list
Rex...@li...
https://lists.sourceforge.net/lists/listinfo/rexxtill-devel
------------------------------------------------------------------------------
Enable your software for Intel(R) Active Management Technology to meet the
growing manageability and security demands of your customers. Businesses
are taking advantage of Intel(R) vPro (TM) technology - will your software
be a part of the solution? Download the Intel(R) Manageability Checker
today! http://p.sf.net/sfu/intel-dev2devmar
_______________________________________________
Rexxtill-devel mailing list
Rex...@li...
https://lists.sourceforge.net/lists/listinfo/rexxtill-devel
------------------------------------------------------------------------------
------------------------------------------------------------------------------
Enable your software for Intel(R) Active Management Technology to meet the
growing manageability and security demands of your customers. Businesses
are taking advantage of Intel(R) vPro (TM) technology - will your software
be a part of the solution? Download the Intel(R) Manageability Checker
today! http://p.sf.net/sfu/intel-dev2devmar
------------------------------------------------------------------------------
_______________________________________________
Rexxtill-devel mailing list
Rex...@li...
https://lists.sourceforge.net/lists/listinfo/rexxtill-devel
|