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 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-devm=105957045726408w=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)
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-devm=105957045726408w=2 See also the answer to them: http://marc.theaimsgroup.com/?l=xml-cocoon-devm=105958517013233w=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 JOINs... 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 database adds/deletes rows from database behind your back. AFAIU this messes up OJB
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)
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=10676139446r=1w=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 are more 'publishing-centric' and which are more 'transaction-centric'. 'publishing-centric'-applications usually don't need flowscript. Your example (reporting tools) is of course a representative of the this type and XSP(using ESQL) or SQL-Transformer
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=StartID=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 get 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)
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)
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=StartID=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)
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
