Modifying the model on the fly in a multi-threaded app is a bit dicey. It is not designed for that. If you had an EOF stack per user, you could clone the model into a new, user specific
EOModelGroup and modify it there.
Chuck
From:
<webobjects-dev-bounces+chill=email@hidden> on behalf of "Morris, Mark" <email@hidden>
Date: Friday, July 8, 2016 at 8:23 PM
To: OC <email@hidden>
Cc: WebObjects-Dev Mailing List <email@hidden>
Subject: Re: Splitting big database tables to speed up?
Just a thought. What about dynamically creating a new EOEntity for each group of T_RECORD records represented by a T_TABLE record? Then you could add a qualifier to the EOEntity that would restrict it to the correct subset, and it would
be included automatically in the SQL. You could use inheritance maybe, or just copy the attributes/relationships from your base entity. Inheritance would let you use your custom java-based logic that’s in the base entity, though.
Alas, my DBTables contain _lots_ of DBRecords, and thus the above implementation would get terribly slow
... my setup is pretty standard, i.e.
- DBTables are represented by rows in one DB table, say, T_TABLE
- all DBRecords of all tables are represented by rows in another DB table, T_RECORD, with a foreign key into T_TABLE.
Therefore, whenever DBTable records are used anyhow, *always* the huge T_RECORD table is filtered by the desired foreign key. Of course there is an index on that column, but since the table contains zillions of records, it is still somewhat
at the slow side.
Conceptually, it would make much better sense to have a separate database table for records of each T_TABLE row: almost all operations need just records of one table; there is a very little or nothing to do over records of more different
tables at once. Database-level, I can pretty well imagine something like many tables named T_RECORD_X where X would be e.g., the primary key of each T_TABLE_ROW. Nevertheless, I can see absolutely no reasonable way of EOmodelling such a thing? (Note that _tables_
-- not just rows -- would have to be added/removed to/from the schema on-the-fly, as users create/delete tables. Table creation/deletion _can_ be slow though; we need table processing to be fast.)
Are there some well-tested tricks for such cases?
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Help/Unsubscribe/Update your Subscription:
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Help/Unsubscribe/Update your Subscription:
|