Re: DB support in flowscript (was: XSP "official" position)
Leszek Gawron dijo: > Could you provide me with some link to OJB docs that describe handling > databases witch triggers modifying the DB content? http://db.apache.org/ojb/how-to-work-with-stored-procedures.html (Follow the document, they create some triggers for Oracle in the sample). Best Regards, Antonio Gallardo
Re: DB support in flowscript (was: XSP "official" position)
On Fri, Nov 21, 2003 at 05:43:00AM -0600, Antonio Gallardo wrote: > > The second case is : > > Imagine you have table that describes building (Building) and then you > > have a > > table that describes the flat (Flat). > > > > Now you want to assign tasks: > > - visit the flat and do something > > - visit the whole building (each flat in the building) > > > > so you add some more tables: > > Task > > TaskBuilding > > TaskFlat > > This can be easily managed using the JDO concept: "extends" inside > classes. BTW, It is a tipical sample in JDO literature. Changes it to: > Employees, Managers, Developers, Sellers, etc. You can have a common base > class "Person". Then you can extend the base class "Person" to another > "Employee" and from Employee to Managers, Developers, Sellers, etc. hmmm I do not really see if this is driven by the same metaphor.. > > So now if you want to query for flats that have not been visited it is > > really > > simple. But now the database adds/deletes rows from database behind your > > back. > > AFAIU this messes up OJB tool completely. Or am I wrong maybe? > > :-D Yes, the last is true. OJB can easily manage this and you will not > have problems. Also you have DB cache and table proxies. Could you provide me with some link to OJB docs that describe handling databases witch triggers modifying the DB content? > Please don't take this mail as an attack. I understand everyone has his > own programming styles and it is often a trade off. I understand you > provided them just as samples to illustrate your points. Exactly, I am still seeking for some convenient way to handle databases. If yours turns up to be better - let it be - I'm just gonna start using it. ouzo -- __ | / \ |Leszek Gawron// \\ \_\\ //_/ [EMAIL PROTECTED] _\\()//_ .'/()\'. Phone: +48(501)720812 / // \\ \ \\ // recursive: adj; see recursive | \__/ |
Re: DB support in flowscript (was: XSP "official" position)
Leszek Gawron dijo: > On Wed, Nov 19, 2003 at 01:36:17PM -0600, Antonio Gallardo wrote: >> >> > - sometimes the db schema makes it impossible to use O/R tools >> >> Show me one. This also denote SQL can be abused. Just for the records, >> we >> are currently building an accounting system and O/R works fine there. >> This >> is the example you said: a 150+ tables. > see http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=105957045726408&w=2 See also the answer to them: http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=105958517013233&w=2 I was reviewing old mails and also found the link to the mail you linked above. At that time, I choosed not answer, because there was already an answer and it was enough to me. Today, while reviewing old mails, I started a new answer to them, but choosed again to not reply and closed the window. It was an old enough mail and tought you already has another opinion to this. But: 1-Any wrapper around any database is slower than direct native DB access. This is a fact. Here I can easily include JDBC, ODBC, etc. When we add any additional instruction for processing, often it is slower. 2-O/R mapping is just an approach to fill the gap between SQL world and OO world (in this case java). 3-Any of the given models you provided in the linked mail can be easily converted to O/R mapping. I don't see why not. Note you saw the problem from the SQL side and not from a OO side. And the view point is very important to understand the solution. Note in O/R mapping you can choosed the level of description. If in a given case you don't need a reference descriptor, you simply don't implement it. That is all. 4-The DB schema 2 and 3 are just design decisions outside the choosed implementation. Simply, it does not matter if I choose to implement with XSP, Java, ODBC, JDO, ADO, DAO, ESQL, C++, C, etc. 5-Personally, I will choose the schema 1, because it is cleaner, easily expandible and has more potential to solve new challenge. Try to explain: What do you do, if your boss one day said: "The management decided to add a new question". How you would manage this in the schema 3? Hehe! It would simply be a hell. I saw in schema 3 a bunch of "ALTER TABLE" that innevitable will add 1,000s of empty fields just to make a "dirty patch". And then? New request how will be solved? Now the boss comes back again and said that they want to see a report involving data accross the questionaries! It would be amazing to see the KB long SQL string we will to send to make 10's of "JOIN"s... of course the same apply for any O/R tool. This is just a design problem again. But this RT are just related to design, regardless the implementation you decide to use. It will be a hell for any of them. My experience said me: "Alway let them the path to grow (or "extend it"?). Users never stop asking new things". (This is again regardless, the implementation). Also, I believe in DB developers. They have hard time trying to find the fastest algorithm to improve DB performance. So I will prefer the 2.5M records + some indexes in ONE table and I am sure it would perform almost as fast than the proposed schema 3 with +100 tables with less info. ...But note all this decisions are related just to design. No matter O/R or SQL. > The second case is : > Imagine you have table that describes building (Building) and then you > have a > table that describes the flat (Flat). > > Now you want to assign tasks: > - visit the flat and do something > - visit the whole building (each flat in the building) > > so you add some more tables: > Task > TaskBuilding > TaskFlat This can be easily managed using the JDO concept: "extends" inside classes. BTW, It is a tipical sample in JDO literature. Changes it to: Employees, Managers, Developers, Sellers, etc. You can have a common base class "Person". Then you can extend the base class "Person" to another "Employee" and from Employee to Managers, Developers, Sellers, etc. It is cleary an OO approach. This is what O/R tools do: allow us think OO. > You also have to add a TaskBuildingFlatVisited table to be able to report > which flats have already been visited if a task was for the whole > building. > > Now the problem: you cannot generate a report simply if you do just > inserts > into the TaskBuildingFlatVisited table, just because you know which flats > HAVE > been visited and it is very hard to query the database for a negated set > (the > flats that have not been visited have no corresponding records in the > database). > So the solution is simple: > > You extend TaskBuildingFlatVisited table with a visited_status column. Now > you > create a trigger on TaskBuilding table that for each building task insert > you > insert all corresponding flat references to TaskBuildingFlatVisited. Now > if a > user visits a flat you do not insert a record - you UPDATE an appropriate > one. > > So now if you want to query for flats that have not been visited it is > really > simple. But now the databa
Re: DB support in flowscript (was: XSP "official" position)
On Wed, Nov 19, 2003 at 01:36:17PM -0600, Antonio Gallardo wrote: > >> > - sometimes the db schema makes it impossible to use O/R tools > > Show me one. This also denote SQL can be abused. Just for the records, we > are currently building an accounting system and O/R works fine there. This > is the example you said: a 150+ tables. see http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=105957045726408&w=2 The second case is : Imagine you have table that describes building (Building) and then you have a table that describes the flat (Flat). Now you want to assign tasks: - visit the flat and do something - visit the whole building (each flat in the building) so you add some more tables: Task TaskBuilding TaskFlat You also have to add a TaskBuildingFlatVisited table to be able to report which flats have already been visited if a task was for the whole building. Now the problem: you cannot generate a report simply if you do just inserts into the TaskBuildingFlatVisited table, just because you know which flats HAVE been visited and it is very hard to query the database for a negated set (the flats that have not been visited have no corresponding records in the database). So the solution is simple: You extend TaskBuildingFlatVisited table with a visited_status column. Now you create a trigger on TaskBuilding table that for each building task insert you insert all corresponding flat references to TaskBuildingFlatVisited. Now if a user visits a flat you do not insert a record - you UPDATE an appropriate one. So now if you want to query for flats that have not been visited it is really simple. But now the database adds/deletes rows from database behind your back. AFAIU this messes up OJB tool completely. Or am I wrong maybe? > > Who said O/R mapping need to be wroten by hand? This is not a MUST > anymore. This is mainly why I go to Druid. Did you know Druid? If not here > is the link: http://druid.apache.org/ :-D This link does not work :) I've been looking at druid but there is one problem: Druid uses some weird technique to detect a JDBC driver in provided jar file. The problem is that Microsoft SQL Server JDBC driver consists of 3 jar files and even if you edit the druid configuration by hand it does not detect the driver class. > > Using Druid making an O/R mapping is a matter fo secs! Is this a problem? > Also + your Beans ready to be used. Well the Beans for JDO are a little > bit slower. But I am sure you will have in less than 2 mins you > database.jar ready to use. So where is the problem? :-DD If you advertise it so strongly I think I will have to try it but first I have to resolve a problem with the M$ JDBC driver. ouzo -- __ | / \ |Leszek Gawron// \\ \_\\ //_/ [EMAIL PROTECTED] _\\()//_ .'/()\'. Phone: +48(501)720812 / // \\ \ \\ // recursive: adj; see recursive | \__/ |
Re: DB support in flowscript (was: XSP "official" position)
On 19 Nov 2003, at 19:03, Tony Collen wrote:
Yep, this is the easy way. I could see this being the answer to some
FAQ:
Q: How can I easily send an email from the Flow layer?
A: The simple way is to write an XSP, and call the XSP's pipeline from
within the Flowscript. If you need something a little cleaner, you
can simply write a helper class in Java and access it from your Flow
as an object.
or:
The Flowscript:
importPackage (Packages.org.apache.cocoon.mail);
function sendMail (smtpHost, bodysrc, to, from, subject, bean) {
var mailer = new MailMessageSender (smtpHost);
mailer.setFrom (from);
mailer.setTo (to);
mailer.setSubject (subject);
// use a JXTemplate to produce the body from the 'bean'
var output = new Packages.java.io.ByteArrayOutputStream ();
cocoon.processPipelineTo (bodysrc, { bean: bean }, output);
mailer.setBody (output.toString ());
mailer.send (null); // a null resolver, because we do not need one
}
NB. MailMessageSender can take a 'src' of a pipeline to call to get the
email body, but it does not take a bean as a parameter. So I can do it
like the above.
The template:
http://apache.org/cocoon/templates/jx/1.0";>
To: #{bean/firstname} #{bean/lastname}.
You have been successfully registered with our site.
http://the.url.here
Your login is: #{bean/email}
We hope you remember your password!
The Pipeline:
HTH
regards Jeremy
smime.p7s
Description: S/MIME cryptographic signature
Re: DB support in flowscript (was: XSP "official" position)
On 19 Nov 2003, at 12:34, Leszek Gawron wrote: Continuing II: I still cannot picture retrieving 5000 of objects via O/R and showing them on paginated view - the performance would be tragical. well ... have you tried it? there was nothing tragic about listing 3 records from Hibernate last time I tried ;) look at : "Scrollable Iteration" : http://www.hibernate.org/hib_docs/reference/html/manipulating- data.html#manipulating-data-s5b and "Lazy Initialisation" : http://www.hibernate.org/hib_docs/reference/html/ collections.html#collections-s1-7 HTH regards Jeremy smime.p7s Description: S/MIME cryptographic signature
Re: DB support in flowscript (was: XSP "official" position)
Tony Collen wrote: Upayavira wrote: I have logged into another PC with PCAnywhere and tried http://charya:8889. (My PC is charya). It didn't work. I removed the Host line, and restarted, and it did. I guess that is reasonably conclusive, isn't it? ;-) Mmmh. Not neccessarily. If the default is to bind to your NIC's public IP (i.e. with no host line), then you'd be able to access Jetty from any computer that can reach that public IP address. As a test I set the host to my public IP address, and I get the following message when I start Jetty: 17:55:04.016 EVENT Started SocketListener on 0.0.0.0: 17:55:04.016 EVENT Started [EMAIL PROTECTED] 17:55:04.086 EVENT Starting Jetty/4.2.9 17:55:04.096 EVENT Started ServletHttpContext[/] 17:55:04.106 EVENT Started SocketListener on [MY_PUBLIC_IP_ADDRESS]:8889 17:55:04.106 EVENT Started [EMAIL PROTECTED] And I was able to access the admin servlet from over the Internet. Likewise, when i set it to 127.0.0.1: 17:56:17.511 EVENT Started SocketListener on 127.0.0.1:8889 And I can only reach the machine from "localhost" (aka 127.0.0.1) It's the IP address it binds to, I tell you! :) Ah. Gocha. It is the interface on which it listens. And if it listens on loopback (127.0.0.1), it'll only hear requests from localhost. If you skip the Host parameter, it'll listen on all interfaces. Makes sense. Regards, Upayavira
Re: DB support in flowscript (was: XSP "official" position)
Upayavira wrote: I have logged into another PC with PCAnywhere and tried http://charya:8889. (My PC is charya). It didn't work. I removed the Host line, and restarted, and it did. I guess that is reasonably conclusive, isn't it? ;-) Mmmh. Not neccessarily. If the default is to bind to your NIC's public IP (i.e. with no host line), then you'd be able to access Jetty from any computer that can reach that public IP address. As a test I set the host to my public IP address, and I get the following message when I start Jetty: 17:55:04.016 EVENT Started SocketListener on 0.0.0.0: 17:55:04.016 EVENT Started [EMAIL PROTECTED] 17:55:04.086 EVENT Starting Jetty/4.2.9 17:55:04.096 EVENT Started ServletHttpContext[/] 17:55:04.106 EVENT Started SocketListener on [MY_PUBLIC_IP_ADDRESS]:8889 17:55:04.106 EVENT Started [EMAIL PROTECTED] And I was able to access the admin servlet from over the Internet. Likewise, when i set it to 127.0.0.1: 17:56:17.511 EVENT Started SocketListener on 127.0.0.1:8889 And I can only reach the machine from "localhost" (aka 127.0.0.1) It's the IP address it binds to, I tell you! :) Tony
Re: DB support in flowscript (was: XSP "official" position)
Tony Collen wrote: Upayavira wrote: Note the 127.0.0.1 line. This sets the host that it will accept connections from. I reckon if you remove this line, it'll accept connections from elsewhere too. I'm no Jetty expert, but wouldn't that be the IP address that it binds to, not the IP address to accept connections fom? Look in the main.xml file, it makes no mention of Host. I have logged into another PC with PCAnywhere and tried http://charya:8889. (My PC is charya). It didn't work. I removed the Host line, and restarted, and it did. I guess that is reasonably conclusive, isn't it? ;-) Regards, Upayavira
Re: DB support in flowscript (was: XSP "official" position)
Upayavira wrote: Note the 127.0.0.1 line. This sets the host that it will accept connections from. I reckon if you remove this line, it'll accept connections from elsewhere too. I'm no Jetty expert, but wouldn't that be the IP address that it binds to, not the IP address to accept connections fom? Regards, Upayavira Tony
Re: DB support in flowscript (was: XSP "official" position)
Ugo Cei wrote: Upayavira wrote: Still a hassle to switch to another window, shut it down, wait., restart, then connect your debugger to the waiting instance, then request a page from Cocoon and wait...:-( Then you don't have a fast enough machine ;-), 700MHz, 512Mb (and full). One day. But I am impressed how long it has lasted (nearly three years). And if you wrote more tests, you wouldn't need a debugger so often. Yup. Will get there. I'm sure once I've started, I'll just keep doing it. It seems you can do a standard http request to, for example http://localhost:8889/?A=Start&ID=1:null:/:0 Ah OK, actually I knew about that, but I tend to forget. Another question, if you don't mind, isn't it possible to use Jetty's admin interface from a host different from localhost? Look in tools/jetty/conf/admin.xml. In there you'll see: 127.0.0.1 5 100 3 5000 Note the 127.0.0.1 line. This sets the host that it will accept connections from. I reckon if you remove this line, it'll accept connections from elsewhere too. Regards, Upayavira
Re: DB support in flowscript (was: XSP "official" position)
Upayavira wrote: Still a hassle to switch to another window, shut it down, wait., restart, then connect your debugger to the waiting instance, then request a page from Cocoon and wait...:-( Then you don't have a fast enough machine ;-), And if you wrote more tests, you wouldn't need a debugger so often. It seems you can do a standard http request to, for example http://localhost:8889/?A=Start&ID=1:null:/:0 Ah OK, actually I knew about that, but I tend to forget. Another question, if you don't mind, isn't it possible to use Jetty's admin interface from a host different from localhost? Ugo
Re: DB support in flowscript (was: XSP "official" position)
Ugo Cei wrote: P.S.: by the way, is it possible to restart a context with Jetty like it is with Tomcat, and how? I've found: http://groups.yahoo.com/group/jetty-support/message/1622 http://jetty.mortbay.org/jetty/doc/reloadServlets.html Tony
Re: DB support in flowscript (was: XSP "official" position)
Ugo Cei wrote: Upayavira wrote: 1) The most complicated bit I have found in building Cocoon sites is handling Java classes. If deployed in a jar, it always seems to require a server/app restart to take on the changes. For trivial things (e.g. sending a simple email), I wouldn't want to have to get all this Java stuff going. Then you should: A) test your classes in isolation _before_ debugging them in Cocoon Yup. Will get into doing that some day soon. B) get yourself a fast machine and with the "cocoon servlet" task, restarting the container is a breeze, especially if you tune your Cocoon to have only the minimum set of blocks needed. Still a hassle to switch to another window, shut it down, wait., restart, then connect your debugger to the waiting instance, then request a page from Cocoon and wait...:-( I'll get there. But then again, YMMV ;-) Ugo P.S.: by the way, is it possible to restart a context with Jetty like it is with Tomcat, and how? Do cocoon servlet-admin and go to http://localhost:8889/ It seems you can do a standard http request to, for example http://localhost:8889/?A=Start&ID=1:null:/:0 (note, I removed the T parameter, which changes every time, and it still seemed to work). I believe you could put this HTTP request into an Ant script using the task. I wonder if there might be a need for a cocoon servlet-debug-admin that allows both debugging and admin (e.g. to allow you to automatically restart your jetty for debugging). Regards, Upayavira
Re: DB support in flowscript (was: XSP "official" position)
Upayavira wrote: 1) The most complicated bit I have found in building Cocoon sites is handling Java classes. If deployed in a jar, it always seems to require a server/app restart to take on the changes. For trivial things (e.g. sending a simple email), I wouldn't want to have to get all this Java stuff going. Then you should: A) test your classes in isolation _before_ debugging them in Cocoon B) get yourself a fast machine and with the "cocoon servlet" task, restarting the container is a breeze, especially if you tune your Cocoon to have only the minimum set of blocks needed. But then again, YMMV ;-) Ugo P.S.: by the way, is it possible to restart a context with Jetty like it is with Tomcat, and how?
Re: DB support in flowscript
Tony Collen dijo: > Ugo Cei wrote: >> Leszek Gawron wrote: >> >>> I'm not advising that also. I am talking about providing an easy >>> framework for >>> database operations that would be available from flow. >> > > I had thought about this for a while... a lightweight JDBC wrapper for the > Flow. > > Then I thought about it more... although it might encourage people to > start writing more things in > Flowscript, I think the Correct Way(tm) would be to write your business > logic in a real Java class > and access it from the Flow that way. > > Remember, the Flow is just for controlling the application. I suppose > then the question is, what > happens when your logic depends on something in a database? +1 Best Regards, Antonio Gallardo
Re: DB support in flowscript (was: XSP "official" position)
Leszek Gawron dijo: > Continuing the example: cocoon is very powerful in presenting reports. I > haven't seen a single report tool that does O/R mapping. Please wait, it is very early to said that. O/R is very new and of course you are right, but it is just a matter of time. I don't said O/R tools are the panacea to all our problems, but mixing SQL + XSP is ugly even if you take advantage of stored procedures. Believe me I, we ended a payroll proyect and it was the worst can us happen: SQL+XSP it is almost unreadable. > Continuing II: I still cannot picture retrieving 5000 of objects via O/R > and > showing them on paginated view - the performance would be tragical. Depends how you do that. For example OJB support proxies and cache. >> > - sometimes the db schema makes it impossible to use O/R tools Show me one. This also denote SQL can be abused. Just for the records, we are currently building an accounting system and O/R works fine there. This is the example you said: a 150+ tables. Who said O/R mapping need to be wroten by hand? This is not a MUST anymore. This is mainly why I go to Druid. Did you know Druid? If not here is the link: http://druid.apache.org/ :-D Using Druid making an O/R mapping is a matter fo secs! Is this a problem? Also + your Beans ready to be used. Well the Beans for JDO are a little bit slower. But I am sure you will have in less than 2 mins you database.jar ready to use. So where is the problem? :-DD As you see we are doing some improvements. I like to think we are innovating in this area. An of course the path is not easy. But I think we will find a Regards at then end. We are learning, how to work with all this stuff and this allow us to think new ideas to be implemented. But please wait, we need also to implement the new ideas too. Of course you can said us: Hey, wait a minut, there is XSP+ESQL+ModActions, why use flow+OJB+JDO at all? Well, let us even fail. If we fail this is a lesson for the community too: The path is wrong. >> that's possible ... >> >> > - in 2 years I haven't found a single project that does not >> > fall under one >> > of above conditions >> > >> > I would really like to contribute to some flow-db block that >> > does not involve O/R mapping but do not know where to start from. >> > >> >> Maybe this helps - I like the idea but don't know if this will work ... >> but I think it worth following it. >> http://marc.theaimsgroup.com/?t=10676139446&r=1&w=2 >> (... but it would be OJB based) >> >> What I don't want to see in a flow-db block is SQL statements ... +1 > I think that it should be possible to choose between O/R and pure database > access. O/R could be a proposed solution and JDBC wrapper a backup one. > ouzo Also, please wait. As soon as we will have time you will see your petstore using OJB too. But just because there is not the OJB petstore this does not mean it can not exists. It is a matter of time. I repeat. Best Regards, Antonio Gallardo
Re: DB support in flowscript (was: XSP "official" position)
Upayavira wrote: 1) The most complicated bit I have found in building Cocoon sites is handling Java classes. If deployed in a jar, it always seems to require a server/app restart to take on the changes. For trivial things (e.g. sending a simple email), I wouldn't want to have to get all this Java stuff going. I agree, this is sort of a pain in the butt. 2) Some Cocoon users aren't Java developers. They may extend to Javascript, but Java will be beyond them. If simple utility classes can be provided that allow such things as sending emails from flow, I don't see the problem. Agreed. IMO though you will get to a level of complexity in your application where you WILL have to code. Maybe it is worth investigating writing some utility scripts for little things like this. 3) I can see the problem with database code in flow. Databases are inherently complicated and incredibly varied. There's a lot less options with sending an email though. Again, I agree. Think about what happens when you have some Flow that accesses an object, which commits some sort of JDO transaction. If you call a previous continuation, you obviously need to rollBack(). Looks a little hairy to me. Regards, Upayavira Tony
RE: DB support in flowscript (was: XSP "official" position)
From: Upayavira > Tony Collen wrote: > ... > > > Yep, this is the easy way. I could see this being the > answer to some > > FAQ: > > > > Q: How can I easily send an email from the Flow layer? > > > > A: The simple way is to write an XSP, and call the XSP's > pipeline from > > within the Flowscript. If you need something a little cleaner, you > > can simply write a helper class in Java and access it from > your Flow > > as an object. > > 1) The most complicated bit I have found in building Cocoon sites is > handling Java classes. If deployed in a jar, it always seems > to require > a server/app restart to take on the changes. For trivial things (e.g. > sending a simple email), I wouldn't want to have to get all this Java > stuff going. you can use hot deployment (at least tomcat supports it) > 2) Some Cocoon users aren't Java developers. They may extend to > Javascript, but Java will be beyond them. Maybe the question is: Is it possible to write 'transaction-centric' applications without knowing Java within Cocoon? I'm not sure about this. Maybe Sylvain's idea using dynamic beans could help here ... > If simple utility > classes can > be provided that allow such things as sending emails from > flow, I don't > see the problem. utiliy classes or pipelines ... +1 for both > 3) I can see the problem with database code in flow. Databases are > inherently complicated and incredibly varied. There's a lot > less options > with sending an email though. yep -- Reinhard
Re: DB support in flowscript (was: XSP "official" position)
Tony Collen wrote: ... Yep, this is the easy way. I could see this being the answer to some FAQ: Q: How can I easily send an email from the Flow layer? A: The simple way is to write an XSP, and call the XSP's pipeline from within the Flowscript. If you need something a little cleaner, you can simply write a helper class in Java and access it from your Flow as an object. 1) The most complicated bit I have found in building Cocoon sites is handling Java classes. If deployed in a jar, it always seems to require a server/app restart to take on the changes. For trivial things (e.g. sending a simple email), I wouldn't want to have to get all this Java stuff going. 2) Some Cocoon users aren't Java developers. They may extend to Javascript, but Java will be beyond them. If simple utility classes can be provided that allow such things as sending emails from flow, I don't see the problem. 3) I can see the problem with database code in flow. Databases are inherently complicated and incredibly varied. There's a lot less options with sending an email though. Regards, Upayavira
Re: DB support in flowscript (was: XSP "official" position)
Reinhard Poetz wrote: If you have to implement transaction logic I think there is no way around Flowscript/CocoonForms/DataObjects(via O/R-mapping or EJB) in order to reach a clean design. I think this is the message for our users. +10. Time to start spreading the gospel :) IMO strong Flow + Forms + OJB / JDO / O/R will get Cocoon widespread acceptance. That, and good documentation :) One further thought on DB and flowscript: If you want to combine the ease of use of XSP and flowscript and you don't want to mix concerns - why don't you call pipelines from within your flowscript? Yep, this is the easy way. I could see this being the answer to some FAQ: Q: How can I easily send an email from the Flow layer? A: The simple way is to write an XSP, and call the XSP's pipeline from within the Flowscript. If you need something a little cleaner, you can simply write a helper class in Java and access it from your Flow as an object. Then you can do all the things XSP/ESQL offer having direct database access. And I don't know how it should become easier if we build a specif 'flow-database-framework' compared to the flexibility of Cocoon pipelines which are called from within the flow layer. This also means that you have caching (--> pipeline caching) for free. Regards, Tony
RE: DB support in flowscript (was: XSP "official" position)
From: Leszek Gawron > On Wed, Nov 19, 2003 at 12:01:41PM +0100, Reinhard Poetz wrote: > > > > From: Leszek Gawron > > > > > On Mon, Nov 17, 2003 at 09:01:57PM -0600, Antonio Gallardo wrote: > > > > I really no wonder why peope still think XSP is the great > > > Gig in the > > > > Cocoon town, because if you google around you will feel this is > > > > the way Cocoon goes. To be honest I don't google about > this for a > > > > long time but still early this year this was the tendency. > > > xsp is very powerful if you use it with esql. > > > > > > - very fast custom database action creation (xsp actions) > > > - nice syntax, no need for enormous amount of JDBC code > needed, no > > > need to > > > handle exceptions > > > - esql is customized transparently for several databases ( > > > i.e. max-rows, > > > skip-rows) - very useful for me because I connect > cocoon to existing > > > database installations so I do not have the comfort to > > > choose one that fits > > > the best. > > > > > > while the flow: > > > - has some database support but is really poor > > > > I wouldn't code my DB support in Javascript > I'm not advising that also. I am talking about providing an > easy framework for database operations that would be > available from flow. > > > and really: why not ? I usually make two scripts : > controller.js and persistence.js. JS has a great feature: it > is interpreted so all you need is a text editor. You just > apply changes and everything works without > - building new classes > - jar packaging > - stopping the container > - replacing the jar > - starting the container > > > > > > - you have to catch exceptions yourself > > > > who else should catch them for you? > SQLExceptions should be beclared or thrown. Simple JDBC > wrappers usually convert almost all of them to > RuntimeExceptions. 90% of exceptions usually denote a design > time or fatal error so there is really no point to recover from them > - it just should be simply logged > > > > > > - no database customizations > > > > I think flowscript shouldn't support DB access directly > Maybe you're right but if you drop XSP what database support > you have? > Actions? Then can be used for really simple processing as > using them for more advanced features makes it harder than > using pure JDBC. > > Please note also that the biggest cocoon application example > - Petstore - accesses database directly from JS. > > > > > > - O/R support is still pre-alpha and even if it was already mature > > > - the overhead is much too big comparing to pure JDBC > for projects > > > not-enterprise size > > > > This is valid for your first project but it's like with > Cocoon: After > > your first Cocoon project many of us also take it as > platform for very > > simple projects. The last few weeks I learned more and more > about OJB > > and you can be sure I'll take it in many projects in the > future - also > > in projects where I wouldn't have taken it in the past because I > > *thought* it is too complicated (in opposite - using OJB > makes it much > > easier!) > > > > > - you cannot use it for web applications that use already ready > > > database > > > schema - try to add some functionality to big accounting > > > system - you > > > would have to map almost whole existing db even if you > > > need access to 3-4 > > > tables > > > > I think if you can remove all those SQL-statements out of your code > > which is IMO very ugly it's worth doing it. > > That's not the point - if you have an accounting system there > are usually about 150 tables (very large). If you implement a > simple plugin to that system you usually are concerned about > a few of them while the OJB would need to map ALL refences > between database tables. > > Continuing the example: cocoon is very powerful in presenting > reports. I haven't seen a single report tool that does O/R mapping. > > Continuing II: I still cannot picture retrieving 5000 of > objects via O/R and showing them on paginated view - the > performance would be tragical. > > > > > > - sometimes the db schema makes it impossible to use O/R tools > > > > that's possible ... > > > > > - in 2 years I haven't found a single project that does not > > > fall under one > > > of above conditions > > > > > > I would really like to contribute to some flow-db block that does > > > not involve O/R mapping but do not know where to start from. > > > > > > > Maybe this helps - I like the idea but don't know if this will work > > ... but I think it worth following it. > > http://marc.theaimsgroup.com/?t=10676139446&r=1&w=2 > > (... but it would be OJB based) > > > > What I don't want to see in a flow-db block is SQL statements ... > I think that it should be possible to choose between O/R and > pure database access. O/R could be a proposed solution and > JDBC wrapper a backup one. I separate between applications which
Re: DB support in flowscript
Ugo Cei wrote: Leszek Gawron wrote: I'm not advising that also. I am talking about providing an easy framework for database operations that would be available from flow. I had thought about this for a while... a lightweight JDBC wrapper for the Flow. Then I thought about it more... although it might encourage people to start writing more things in Flowscript, I think the Correct Way(tm) would be to write your business logic in a real Java class and access it from the Flow that way. Remember, the Flow is just for controlling the application. I suppose then the question is, what happens when your logic depends on something in a database? Which kind of framework? What patterns would it implement? If you take a look at Martin Fowler's catalog of Enterprise Application Patterns [1], you'll see quite a few having to do with accessing data sources. What I'm trying to say is that there is no "right way" to implement this, so I'm -0.5 against providing any kind of JDBC encapsulation code in flowscript, like it were some kind of "best practice". I would have to agree with this. It's tempting to make the Flow "as easy as PHP" and just give everybody tons of functions to do stuff with. The problem is if we provide too much, then people will just start writing EVERYTHING in the Flow, and before you know it, it's out of hand. I guess the same would go for the use case of wanting to fire off a simple email message from the Flow. But I guess if the user wants to do something that complicated, it would be trivial for them to just write a helper class in Java that they could access through Packages.* Thoughts? Tony
Re: DB support in flowscript
Leszek Gawron wrote: I'm not advising that also. I am talking about providing an easy framework for database operations that would be available from flow. Which kind of framework? What patterns would it implement? If you take a look at Martin Fowler's catalog of Enterprise Application Patterns [1], you'll see quite a few having to do with accessing data sources. What I'm trying to say is that there is no "right way" to implement this, so I'm -0.5 against providing any kind of JDBC encapsulation code in flowscript, like it were some kind of "best practice". Ugo [1] http://www.martinfowler.com/eaaCatalog/
Re: DB support in flowscript (was: XSP "official" position)
On Wed, Nov 19, 2003 at 12:01:41PM +0100, Reinhard Poetz wrote: > > From: Leszek Gawron > > > On Mon, Nov 17, 2003 at 09:01:57PM -0600, Antonio Gallardo wrote: > > > I really no wonder why peope still think XSP is the great > > Gig in the > > > Cocoon town, because if you google around you will feel this is the > > > way Cocoon goes. To be honest I don't google about this for a long > > > time but still early this year this was the tendency. > > xsp is very powerful if you use it with esql. > > > > - very fast custom database action creation (xsp actions) > > - nice syntax, no need for enormous amount of JDBC code > > needed, no need to > > handle exceptions > > - esql is customized transparently for several databases ( > > i.e. max-rows, > > skip-rows) - very useful for me because I connect cocoon to existing > > database installations so I do not have the comfort to > > choose one that fits > > the best. > > > > while the flow: > > - has some database support but is really poor > > I wouldn't code my DB support in Javascript I'm not advising that also. I am talking about providing an easy framework for database operations that would be available from flow. and really: why not ? I usually make two scripts : controller.js and persistence.js. JS has a great feature: it is interpreted so all you need is a text editor. You just apply changes and everything works without - building new classes - jar packaging - stopping the container - replacing the jar - starting the container > > > - you have to catch exceptions yourself > > who else should catch them for you? SQLExceptions should be beclared or thrown. Simple JDBC wrappers usually convert almost all of them to RuntimeExceptions. 90% of exceptions usually denote a design time or fatal error so there is really no point to recover from them - it just should be simply logged > > > - no database customizations > > I think flowscript shouldn't support DB access directly Maybe you're right but if you drop XSP what database support you have? Actions? Then can be used for really simple processing as using them for more advanced features makes it harder than using pure JDBC. Please note also that the biggest cocoon application example - Petstore - accesses database directly from JS. > > > - O/R support is still pre-alpha and even if it was already mature > > - the overhead is much too big comparing to pure JDBC for projects > > not-enterprise size > > This is valid for your first project but it's like with Cocoon: After > your first Cocoon project many of us also take it as platform for very > simple projects. > The last few weeks I learned more and more about OJB and you can be sure > I'll take it in many projects in the future - also in projects where I > wouldn't have taken it in the past because I *thought* it is too > complicated (in opposite - using OJB makes it much easier!) > > > - you cannot use it for web applications that use already > > ready database > > schema - try to add some functionality to big accounting > > system - you > > would have to map almost whole existing db even if you > > need access to 3-4 > > tables > > I think if you can remove all those SQL-statements out of your code > which is IMO very ugly it's worth doing it. That's not the point - if you have an accounting system there are usually about 150 tables (very large). If you implement a simple plugin to that system you usually are concerned about a few of them while the OJB would need to map ALL refences between database tables. Continuing the example: cocoon is very powerful in presenting reports. I haven't seen a single report tool that does O/R mapping. Continuing II: I still cannot picture retrieving 5000 of objects via O/R and showing them on paginated view - the performance would be tragical. > > > - sometimes the db schema makes it impossible to use O/R tools > > that's possible ... > > > - in 2 years I haven't found a single project that does not > > fall under one > > of above conditions > > > > I would really like to contribute to some flow-db block that > > does not involve O/R mapping but do not know where to start from. > > > > Maybe this helps - I like the idea but don't know if this will work ... > but I think it worth following it. > http://marc.theaimsgroup.com/?t=10676139446&r=1&w=2 > (... but it would be OJB based) > > What I don't want to see in a flow-db block is SQL statements ... I think that it should be possible to choose between O/R and pure database access. O/R could be a proposed solution and JDBC wrapper a backup one. ouzo -- __ | / \ |Leszek Gawron// \\ \_\\ //_/ [EMAIL PROTECTED] _\\()//_ .'/()\'. Phone: +48(501)720812 / // \\ \ \\ // recursive: adj; see recursive | \__/ |
DB support in flowscript (was: XSP "official" position)
From: Leszek Gawron > On Mon, Nov 17, 2003 at 09:01:57PM -0600, Antonio Gallardo wrote: > > I really no wonder why peope still think XSP is the great > Gig in the > > Cocoon town, because if you google around you will feel this is the > > way Cocoon goes. To be honest I don't google about this for a long > > time but still early this year this was the tendency. > xsp is very powerful if you use it with esql. > > - very fast custom database action creation (xsp actions) > - nice syntax, no need for enormous amount of JDBC code > needed, no need to > handle exceptions > - esql is customized transparently for several databases ( > i.e. max-rows, > skip-rows) - very useful for me because I connect cocoon to existing > database installations so I do not have the comfort to > choose one that fits > the best. > > while the flow: > - has some database support but is really poor I wouldn't code my DB support in Javascript > - you have to catch exceptions yourself who else should catch them for you? > - no database customizations I think flowscript shouldn't support DB access directly > - O/R support is still pre-alpha and even if it was already mature > - the overhead is much too big comparing to pure JDBC for projects > not-enterprise size This is valid for your first project but it's like with Cocoon: After your first Cocoon project many of us also take it as platform for very simple projects. The last few weeks I learned more and more about OJB and you can be sure I'll take it in many projects in the future - also in projects where I wouldn't have taken it in the past because I *thought* it is too complicated (in opposite - using OJB makes it much easier!) > - you cannot use it for web applications that use already > ready database > schema - try to add some functionality to big accounting > system - you > would have to map almost whole existing db even if you > need access to 3-4 > tables I think if you can remove all those SQL-statements out of your code which is IMO very ugly it's worth doing it. > - sometimes the db schema makes it impossible to use O/R tools that's possible ... > - in 2 years I haven't found a single project that does not > fall under one > of above conditions > > I would really like to contribute to some flow-db block that > does not involve O/R mapping but do not know where to start from. > Maybe this helps - I like the idea but don't know if this will work ... but I think it worth following it. http://marc.theaimsgroup.com/?t=10676139446&r=1&w=2 (... but it would be OJB based) What I don't want to see in a flow-db block is SQL statements ... -- Reinhard
