[jae77]

i'm going to add it to the properties files that defines the settings for the databases.

these are the files that live in build/etc and contain the mapping name, merge dir, etc.

[lcb]

jae,
you have added nukes.pk-constraint to the properties files for the database, but you forgott to use this property in your build script.
I think change the build.xml like this will fix it:

<target name="configure" unless="configure.disable">

 <property name="jndi-root" value="nukes/news"/>
 <property name="news.create-table" value="true"/>
 <property name="news.remove-table" value="false"/>
 <property name="news.pk-constraint" value="${nukes.pk-constraint}"/>

[jae77]

i have the correct changes on my local machine, but they aren't checked in yet. (should be done later this evening once i'm home from the day job).

for now you can just modify it locally if you're testing out the alpha release. don't get too attached to any news items you created b/c the tables did change again due to a weird cmp bug (which has now been fixed for 3.2.4) and some additional columns.

[hxp]

for the "WHY" part --- the context within which to understand this--- go to:
Pure-CMP & FAQ Module revamp
http://www.jboss.org/index.html?module=bb&op=viewtopic&t=49034

"hxp" wrote:
HOW-TO FOR UNKNOWN-PK

To use unknown-pk, the Entity EJB must not have a PK field.

<primkey-field> must be missing from ejb-jar.xml!
No getter, no setter! ...and therefore no place to put per-field xdoclet tagging. Rather, up at the class level, you need xdoclet stuff like this:

* @jboss.unknown-pk
* class="java.lang.Long"
* column-name="pn_id"
* field-name="id"
 * auto-increment = "true"
* jdbc-type="NUMERIC"
* sql-type="NUMERIC"

or

* @jboss.unknown-pk
 * class = "java.lang.Integer"
 * sql-type = "INTEGER"
 * jdbc-type = "INTEGER"
 * auto-increment = "true"
 * field-name = "id"
 * column-name = "pn_id"

can be, but does not have to be, Integer.

i understand the need for the unknown-pk stuff if you are not using an integer as the pk for the database

nope. orthogonal issues. you never "have to" use unknown pk. (you just picked up some misinformation somewhere.... kinda easy to do, in this wild open src doco jungle ;)

* So the Java type of the unknown-PK must be a subtype of java.lang.Object (not too restrictive, eh).... obviously cant be a primitive type..... but should map to a SQL-standard column type.... so without me going and looking up the outer limits of what's allowed here, lets just realize something ----- you can set up fancy finders on any combination of fields, and you can index non-PK fields for performance if necessary.... so you can just use a simple straightforward convention: always have a PK that has nothing to do with the actual data in the Entity!

That's right, screw compound-keys, or custom PK-classes, or stupid stuff like BLOBs as PKs 8-() .... yeah, DBA-geeks with nothing better to do can optimize all night long down at the DBMS internals level... but lets get down to real reality...... just use Integer, Long, or String as the Java type of the unknown-PK, and be done with it!

* In interface implementations, to satisfy general signatures, methods that return a PK must return java.lang.Object .... such as ejbCreate() ... and method/finder that takes a PK as a param (such as findByPrimaryKey()) must take an Object (and cast it internally).... but Queries cant cast, so they take the actual type (a bit confusing, perhaps even a spec bug somewhere ;)) But if you do it the wrong way, you get:

org.jboss.deployment.DeploymentException:
Error compiling EJB-QL statement
'SELECT OBJECT(f) FROM faq AS f where f.category.id = ?1 and f.answer <> ''';
- nested throwable: (org.jboss.ejb.plugins.cmp.ejbql.ParseException:
 Encountered "1" at line 1, column 54. ....

* There is no setter, of course... and there is a special getter:
Note use of this unknown-pk idiom within QuoteModule.java:

(Integer) quoteEJB.getPrimaryKey()

So you've got to go thru and convert all your lines of code that have a *.getId()

* @ejb.pk
 * class = "java.lang.Object"
 * generate = "false"

..... generate = "false" is GOOD for unknown-PK, since JBoss is not doing the generating; the underlying DBMS is doing the generating!

When I get a chance, I'll edit this into better docco, but together with the examples in the Quotes and FAQ modules, this ought to be enuf to get folks started.

-- Howard

[hxp]

Julien, Jae ---

I may have screwed up somehow, but before going to sleep, I thought I'd do a complete from-scratch reinstall -- virgin jboss3.2.3, update from CVS, set local.properties for hsqldb, went thru InstallUninstallUpgrade build steps and ran installer --- and there are all sorts of symptoms that something is wrong with a consistent systemwide setting of which DB to use....

"Cannot connect to database" when trying to do first access from browser after installer; "NukesDS not bound" in console; no nukes-ds.xml in deploy dir (after installer has been run).... and when i copied over a hsqldb-based nukes-ds.xml manually, then lots of console msgs indicated that most of nukes thought it was trying to access a mysql db. :-(

Please take a look and do some tests; let me know if any of my new stuff caused any of this; let me know if other changes you guys are making are causing any of this; or any other hints.

> 4am; too tired to go further right now.

-- Howard

[hxp]

hunches ---

the DDL in setup.xml's should be stripped out for pure-CMP modules: News, Quotes, FAQ.

maybe why this interaction wasnt showing up from normal testing is that the only time the interaction bites is after doing a complete install (running installer, executing DDL) ...?

-h