In need of a DAO abstraction layer

[GoogleCodeExporter]

With things as they are now, it's impossible to access an object through 
the DAOs unless it's exact type is known.

While it's true that, at this early stage of development, we still have 
very few different DAOs and every message has very reduced, specific 
functionality (i.e. the type of object to request is always known 
beforehand) this will most probably not be the case at some point later on.

Thus, the need will arise eventually for an extra abstraction layer that 
allows access to objects with nothing but their unique object ID (OID). To 
avoid a global slowdown of object access, we could create a method in the 
Entity DAO that returns an object from it's OID and type, and have this 
second parameter be optional.

The number of changes to be made then can be greatly reduced if we 
implement the method NOW, but have the type parameter be mandatory.

Original issue reported on code.google.com by slezica89@gmail.com on 21 Apr 2010 at 4:48

[GoogleCodeExporter]

Picture this:

dao.get(oid = 1134, type = OT_CHARACTER or OT_NPC)

Original comment by slezica89@gmail.com on 21 Apr 2010 at 4:50

[GoogleCodeExporter]

SQLAlchemy does not provide a way to cast objects to the correct type from a 
Generic 
DAO. Technically, DAOs are just wrapped-up sessions with an associated model 
(class), 
and that's why there are so many DAOs.

If you want a Global DAO, then I can provide you with something like:

  SceneDAO.get(id)

Where id would be the object's id (I'm quite original, I know!). Keep in mind 
this 
would force us to query the database twice: first to get the basic information 
of the 
object and *then* to query for the rest of the information. Memorization could 
speed 
up the first search, though.

I'll keep an eye on the rest of the code to see if we really need this or if I 
can 
implement an Engine-Oriented DAO instead of a Model-Oriented one.

Original comment by rhfi...@gmail.com on 21 Apr 2010 at 6:16

• Added labels: Priority-Low, Maintainability
• Removed labels: Priority-Medium

[GoogleCodeExporter]

Mmm still not ideal, because of the query duplication thing. How about,... (I 
don't 
promise any traces of logic in what follows, my understanding of the DB part of 
code 
is at best very limited):

About the object IDs, do they need to be sequential? Are they arbitrarily 
assigned 
numbers, or places in a table? In the former case, how about we use a smarter 
algorithm for OID assignment? One that stores type information in the OID?

Something as simple and unrefined as...

NEW_OID = ((TOTAL_OBJECTS_OF_THIS_TYPE) * TOTAL_OBJECT_TYPES) + TYPE_CONSTANT

... would then allow us to get an object type from it's OID using a simple 
modulo 
operation. An object's (OID % TOTAL_OBJECT_TYPES) would evaluate to 
TYPE_CONSTANT.

Original comment by slezica89@gmail.com on 21 Apr 2010 at 6:57