So I have a table for api accounts
Table "public.api_useraccount"
Column | Type
| Modifiers
--------------------------------+-----------------------------
+--------------------------------------------------------------
id | integer | not
null default nextval('api_useraccount_id_seq'::regclass)
etc
and 3 types of API keys.
since each type of API key is quite different, I have 3 seperate api
key tables
lets just look at key portions of 2
Table "public.api_key"
Column | Type |
Modifiers
--------------------+-----------------------
+------------------------------------------------------
id | bigint | not null default
nextval('api_key_id_seq'::regclass)
api_useraccount_id | integer | not null
api_key | character(12) | not null
key_name | character varying(32) |
Table "public.api_application_key"
Column | Type
| Modifiers
---------------------+-----------------------
+------------------------------------------------------------------
id | bigint | not null default
nextval('api_application_key_id_seq'::regclass)
api_useraccount_id | integer | not null
api_application_key | character(14) | not null
application_name | character varying(32) | not null
application_version | character varying(32) |
the similaritty of column names makes rose unhappy when i do some
things.
some things like a manager load with_objects...
with_objects=> [
'api_keys',
'api_application_keys',
'api_quicklist_keys',
],
creates this sql
SELECT
t1.id,
etc
t2.api_key,
t2.api_useraccount_id,
t2.id,
t2.key_name,
t3.api_application_key,
t3.api_useraccount_id,
t3.application_name,
t3.application_version,
t3.id,
t4.api_useraccount_id,
t4.application_name,
t4.application_version,
t4.id,
t4.key__private,
t4.key__public
FROM
api_useraccount t1
LEFT OUTER JOIN api_key t2 ON (t1.id = t2.api_useraccount_id)
LEFT OUTER JOIN api_application_key t3 ON (t1.id =
t3.api_useraccount_id)
LEFT OUTER JOIN api_quicklist_key t4 ON (t1.id =
t4.api_useraccount_id)
WHERE
t1.useraccount_id =
Notice the issue ?
on the return, there is a ton of overlap on the column names.
when rose stars trying to build objects, it often sees null values --
because t2.api_key is populated, but its reading t3.api_key when it
looks at api_key in the result row.
the only way i can envision a fix is by doing something like this;
SELECT t1.available_api_application_keys AS
t1_available_api_application_keys
and using a lookup hash to map t1_available_api_application_keys to
the t1 object and column when creating objects
// Jonathan Vanasco
| - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - - - -
| SyndiClick.com
| - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - - - -
| FindMeOn.com - The cure for Multiple Web Personality Disorder
| Web Identity Management and 3D Social Networking
| - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - - - -
| RoadSound.com - Tools For Bands, Stuff For Fans
| Collaborative Online Management And Syndication Tools
| - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - - - -
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Rose-db-object mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/rose-db-object
