Textual Query Language

Posts   
 
    
Mephyston
User
Posts: 6
Joined: 26-Jul-2006
# Posted on: 18-Aug-2006 16:32:26   

Hello,

I have in my Oracle Database a series of tables with have the same structure but witch are not mapped by LLBLGEN because of the possibility for my client to add new identical tables when he wants.

However, I have to acces to these tables. My question is :

  • It is possible to use textual query language with LLBLGEN PRO v2.0 ?
  • If no, it is possible to use the connection of the generated code with textual query language ?

Thx, Mephyston

Edit : I hope I'm understandable...

bclubb
User
Posts: 934
Joined: 12-Feb-2004
# Posted on: 19-Aug-2006 02:08:07   

What are you wanting to do with the tables that are not in the generated code? I don't believe there is a way to access non mapped tables.

Puromtec
User
Posts: 76
Joined: 22-Jun-2005
# Posted on: 22-Aug-2006 16:06:05   

I think I have at least a partial solution for you:

  1. Because they are of the same structure, you can create an oracle synonym on for an initial table (of the proper strucure).

  2. Build LLBLGen project using this synonym as the source.

  3. During runtime of the end-user application, have a mechanism that runs "raw sql" commands that re-map the synonym to the chosen underlying table (that has random name).

oracle synonym command "create or replace synonym synName for " + newTablename

This way llblgen doesn't care what exactly the underlying table name is. Your only drawback is that you can only have 1 user at a time access the database system.

Alternatively, you can have a drawn out process of maintaining the list of tables as meta data in the database and generating your own LLBL code to handle each type. I've done similar.

Hope this helps.

-Darren

Jessynoo avatar
Jessynoo
Support Team
Posts: 296
Joined: 19-Aug-2004
# Posted on: 22-Aug-2006 17:17:36   

Hi,

If the structure keeps the same, and if you keep in charge of the db accesses, can't you simply add other columns like userID to your table and keep them hidden to your users?

Then for sql text queries, you can try playing with RetrievalQueries and FetchDataReader, which you could even combine with projectors to your main entity.

The last solution would be to change the presistenceInfo objects at runtime. That would probably involve making the PersistenceInfoProvider Public in the first place, then add new mappings and change the entity/entityfields properties such as "ContainingObjectName" with probably some more plumbings. I can't tell you the exact procedure.

I would go for the first solution if possible...