I'm new to sqlalchemy and am trying to map several tables to a class.
The tables are constructed like so:
Types
-typeID
-typeName
-groupID
...
TypeAttributes
-typeID
-attributeID
-attributeValueInt
-attributeValueFloat
The idea is to have sqlalchemy map a from TypeAttributes to normal class attributes.
As added complexity attributeValueInt and attributeValueFloat are exclusive. By which I mean each attributeID will have either an int or a float assossiated and the other will be null.
Any ideas how this could be done? or advice on a better way to do it (I have no control over the Database itself).
Have a look at this question: How to map one class against multiple tables with SQLAlchemy?
Related
I have an SQLAlchemy model class model, a string denoting an attribute/column attr that corresponds to an ORM relationship with another model class othermodel, and a private key or id string of such an othermodel.
I would like to find the object othermodel.get(id) to store it in a newly constructed instance, using like setattr(model(), attr, ???) – but I don't have that othermodel accessible in a variable. How do I get that?
I assume I can use some kind of introspection on model or its new instance, but how?
Digging through
model's attributes, I found a copy of othermodel in
getattr(model, attr).comparator.property.argument
turning my assignment into
setattr(model(), attr, getattr(model, attr).comparator.property.argument.get(id))
Quite a mouthful!
This looks reasonable for the moment, but I am quite sure I am missing a more obvious way to access it.
Which of the following structures would be preferable:
# M2M
class UserProfile(models.Model):
...
groups = models.ManyToManyField(Group)
class Group(models.Model):
...
or -
# 2 FKs
class UserProfile(models.Model):
...
class Group(models.Models):
...
class GroupMember(models.Model):
user = models.ForeignKey(UserProfile)
group = models.ForeignKey(Group)
Which would be better?
You also can combine these 2 variants using through option
groups = models.ManyToManyField(Group, through='GroupMember')
What do you mean by better? Usually you don't need to create intermediate model (except the case when you have to store extra data).
ManyToManyField does his job perfectly, so don't write its functionality by yourself.
The two are essentially the same. When you do a M2M Django automatically creates a intermediary model, which is pretty much exactly like your GroupMember model. However, it also sets up some API hooks allowing you to access the Group model directly from the UserProfile model, without have to mess with the intermediary model.
You can get the same hooks added back by using through as #San4ez explains, but you've only made things more complicated. Creating a custom through model is only beneficial if you need to add additional fields to the relationship. Otherwise, stick with the default.
Long and short, #1 is better, only because it's exactly the same as #2, but simpler and with no extraneous code.
Using sqlalchemy 0.7.2
Is there a way to find the table class from the query object? For example:
q = session.query(Customers)
how can I find Customers in q? Possible? Not Possible?
Yes. You need column_descriptions.
It's a long road to the table, though. sqlalchemy.orm.Query.column_descriptions returns a list of dicts, describing each query entity as it was given to query. in your example, there's only one entity, so you need the first item from that list. And since you're interested in the type of the query entity, rather than its' structure, you want the "type" key from that list:
q_entity = q.column_descriptions[0]['type']
assert q_entity == Customer
Accessing the table for the mapped class requires snooping around in the mapper subsystem. for that, you should use manager_of_class. The table is accessible from the manager through the mapper.mapped_table attribute:
from sqlalchemy.orm.attribute import manager_of_class
q_table = manager_of_class(q_entity).mapper.mapped_table
Resist the urge to skip strait to the mapper through Customer.__mapper__, or even Customer.__table__; That's specific to sqlalchemy.ext.declarative, and won't work with classes that are mapped by other means.
I have this problem:
The Vehicle type derives from the EntityObject type which has the property "ID".
I think i get why L2S can't translate this into SQL- it does not know that the WHERE clause should include WHERE VehicleId == value. VehicleId btw is the PK on the table, whereas the property in the object model, as above, is "ID".
Can I even win on this with an Expression tree? Because it seems easy enough to create an Expression to pass to the SingleOrDefault method but will L2S still fail to translate it?
I'm trying to be DDD friendly so I don't want to decorate my domain model objects with ColumnAttributes etc. I am happy however to customize my L2S dbml file and add Expression helpers/whatever in my "data layer" in the hope of keeping this ORM-business far from my domain model.
Update:
I'm not using the object initialization syntax in my select statement. Like this:
private IQueryable<Vehicle> Vehicles()
{
return from vehicle in _dc
select new Vehicle() { ID = vehicle.VehicleId };
}
I'm actually using a constructor and from what I've read this will cause the above problem. This is what I'm doing:
private IQueryable<Vehicle> Vehicles()
{
return from vehicle in _dc
select new Vehicle(vehicle.VehicleId);
}
I understand that L2S can't translate the expression tree from the screen grab above because it does not know the mappings which it would usually infer from the object initialization syntax. How can I get around this? Do I need to build a Expression with the attribute bindings?
I have decided that this is not possible from further experience.
L2S simply can not create the correct WHERE clause when a parameterized ctor is used in the mapping projection. It's the initializer syntax in conventional L2S mapping projections which gives L2S the context it needs.
Short answer - use NHibernate.
Short answer: Don't.
I once tried to apply the IQueryable<.IEntity> to Linq2Sql. I got burned bad.
As you said. L2S (and EF too in this regard) doesn't know that ID is mapped to the column VehicleId. You could get around this by refactoring your Vehicle.ID to Vehicle.VehicleID. (Yes, they work if they are the same name). However I still don't recommend it.
Use L2S with the object it provided. Masking an extra layer over it while working with IQueryable ... is bad IMO (from my experience).
Otherway is to do .ToList() after you have done the select statement. This loads all the vehicles into your memory. Then you do the .Where statment against Linq 2 Object collections. Ofcourse this won't be as effecient as L2S handles all of the query and causes larger memory usage.
Long story short. Don't use Sql IQueryable with any object other than the ones it was originally designed for. It just doesn't work (well).
I am having trouble with inheritance mapping in Linq to Sql. I am using MSDN as a reference and as a basis it sounds good. However the example it gives is a single table inheritance mapping. However, I am trying to do multiple table inheritance to save on table space. Is this possible? So far I have:
[Table(Name="writing_objs")]
[InheritanceMapping(Code="T",Type=typeof(ObjectTypeA), IsDefault=true)] // Only default because a default is required
[InheritanceMapping(Code="N",Type=typeof(ObjectTypeb))]
public abstract class WritingObject
{
/* ... */
[Column(Name="obj_tp", IsDiscriminator=true)]
[StringLength(1)]
public string ObjectType { get; set; }
}
I then have the different object types defined like so:
[Table(Name="obj_type_a")]
public class ObjectTypeA: WritingObject
{
/* Object Type A fields */
}
The issue seems to be that I am defining a table attribute in the 2nd type, as I get the following exception:
The inheritance subtype 'ObjectTypeA' is also declared as a root type.
Is it possible to keep these fields in separate tables with Linq to Sql or am I going to have to consolidate them all into a single table? Is it necessarily bad to have some extra fields in one table as long as there aren't too many (some object types might even be able to share some fields)?
Linq to SQL does not support multiple-table inheritance using a discriminator, even though that is the best design in many cases (it's the most normalized).
You'll have to implement it using associations instead. If you use a mapping layer that converts it to an inheritance-based domain model, it will be easier to manage at higher layers.
Well I know this problem has already been resolved, but as I just encountered the same issue, I'd like to share what I did :
Just remove the [Table] attribute from your inherited classes. And it's quite logical, because we define in the generic classes a way to store all subtypes (with the discriminatory attrbute).
Maybe this will help someone in the future.