Slight change here, I used a property instead of a filter token. I also dropped the
filter-sources target but I replaced it with a regex-sources to address a limitation
with EJBQL and CLOB comparisons.
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3852617#385
Ok, here's what I've done:
- Added the boolean prop "nukes.pk-auto-increment" for each database conf in:
/build/etc/*
- Added the prop "build.gen.src" to set the filter copy destination directory in:
/tools/etc/buildfragents/defaults.ent
- Added the target "_default:filter-sources" to perform
In brief, I need to switch the xdoclet tag for "auto-increment" to false from true
when building Nukes for Oracle. I'm thinking the best way is to use an Ant
filter/replace to achieve this with a token like @autoincrement@ and incorporating the
filter into the build file for each module. The re
To close out this thread, it turned out to be a bug in XDoclet (I've submitted a
patch), so there's no further action needed by the Nukes team.
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3850292#3850292
Reply to the post :
http://www.jboss.org/index.html?
Ok, then there's a bug in there somewhere since it's not generating Oracle compatible
SQL for the SQL I cited. I'll setup some debug hooks and find the root cause. Thanks
Julien.
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3849750#3849750
Reply to the post
Standalone Tomcat cannot work with Nukes since Nukes uses EJBs while Tomcat is not an
EJB container. The JBoss with embedded Tomcat combination works with Nukes since JBoss
provides the EJB container.
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3849741#384
Ok, some SQL statements used in the EJB xdoclet defs extend beyond SQL92 causing
portability issues. To cite a particular example, from
org.jboss.nukes.core.ejb.FileEJB:
SELECT DISTINCT SUBSTRING(f.fileId, 1, LOCATE('/', f.fileId, LENGTH(?1) + 2)) FROM
file AS f WHERE f.fileId LIKE CONCAT(?1,
Thanks Thomas ... I'll change it to "comments" like I mentioned and get it all checked
back in.
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3849670#3849670
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3849670
To keep it brief, the table phpbb_attachments_desc, which is currently only in cvs
heads' bb module, contains a column named "comment" which is a reserved word in
Oracle. There is no painless workaround for this restriction so I would like to rename
that column from "comment" to "comments". At a
Good point, it would be in the form "nukes10.xml" in a setup.xml flavor, not a plain
SQL script, my bad there.
I also agree with your second point, Oracle's ability to deal with table structure
changes in-db varies quite a bit by Oracle version so exp/imp is the easiest
catch-alll solution for
I'm looking for some kind of consensus as to an appropriate location for database
specific but module generic one-time use SQL scripts? The reasoning is that any
changes to indexing, triggers, etc would be reflected in the setup.xml file -but- for
existing installations, the end user would obvi
11 matches
Mail list logo
