I am trying to create 'virtual' DataSkins that totally live in a SQL database. How do I create a new item in a rack without providing an initial ID for the object? Here's what I've been doing so far... 1. I have Storage set to "loaded by accessing attribute 'id'". 2. I have an ADD trigger that creates a MySql row and returns the LAST_INSERT_ID() as "id" ("Keeping:id=RESULT.new_obj"). 3. I have a CHANGE trigger that updates the MySql row with attributes. 4. I have a CatalogTrigger. Now it almost works when I try to add an object with key=random() by: <dtml-let ni="newItem(key)" nips="ni.propertysheets.get('Basic')"> <dtml-call "nips.manage_changeProperties(REQUEST)"> So what I belive this is doing is creating a temperery object then changing it's ID (which sounds very screwy). The problem I am having is first of all the Catalog is indexing the temporery random key not the one returned from the CREATE trigger. Please advise. Also in my CHANGE trigger I am calling SQL like this: UPDATE sc_account SET <dtml-in CHANGED_ATTRS> <dtml-var sequence-item>= <dtml-var expr="_.getattr(object,_['sequence-item'])" sql_quote> <dtml-unless sequence-end>,</dtml-unless> </dtml-in> This updates all my 'string' fields but not the 'int' ones I think because they are quoted by "sql_quote" (although I'm not sure). Please advise. I know this is a rambling email but I would greatly appreciate your help in creating DataSkins that are stored in RDBMS not persistently. Once I get this working I'll post a full How-To (unless there is one already that I've missed). -Ben
At 01:58 PM 11/23/00 -0500, bentzion@bellatlantic.net wrote:
I am trying to create 'virtual' DataSkins that totally live in a SQL database. How do I create a new item in a rack without providing an initial ID for the object?
You can't. To do what you're trying to do, you would need to implement a "newKey" function in the Specialist that creates the row, but with contents that would still cause your attribute providers to pretend the object doesn't yet exist. Basically, ZPatterns as it is now does not provide support for creating an object without first knowing its ID. This means that it's hard to support autogenerated database ID's, but I suggest rethinking your design a bit. Using keys that are identity columns is often a bad idea, since reloading data tends to mess them up or reassign them, that sort of thing. I have found it to usually be better to have a seperate counter that issues ID's that then are guaranteed to never be re-issued to the wrong object. Also, by seperating ID generation from insertion you can often gain concurrency in multi-user applications (because you can generate ID's on a seperate connection, in a seperate transaction). Even if you prefer to use a directly autogenerated integer key for referential integrity purposes, in most application domains there is a domain-specific primary key that can/should be used as your 'id' attribute.
participants (2)
-
bentzion＠bellatlantic.net -
Phillip J. Eby