Django Web Framework: The 'D' is silent dumbass

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Django Web Framework: The 'D' is silent dumbass

«‹›122 »

Sparta: Aug 14, 2003; the other white meat

Suspicious Dish posted:

This is a bad idea. You're removing the big benefit of having a database keep all the data and build relationships. What if there are actually two separate Daniel Radcliffes that are actors? It's not uncommon to have two different actors with the same name.

http://en.wikipedia.org/wiki/Screen_Actors_Guild#Unique_stage_names

You could also just use a primary_key, or make the name primary (which would force things like Daniel Radcliffe (II) if there were more than one).

And building up individual Cast entries per movie is literally no different; if he wants to pull a list of all roles Daniel Radcliffe has been in, he still has to do a search through all of Cast for name="Daniel Radcliffe" -- which would run in to the very same problem you have said occurs with my version.

# ? May 29, 2012 20:23

Adbot: ADBOT LOVES YOU

# ? Jun 6, 2024 09:02

Suspicious Dish: Sep 24, 2011; 2020 is the year of linux on the desktop, bro; Fun Shoe

Sparta posted:

http://en.wikipedia.org/wiki/Screen_Actors_Guild#Unique_stage_names

The rule has been relaxed considerably, and not all productions require actors to be in the Screen Actors Guild, especially independent productions. There's also no similar rule for any of the unions of production crew members.

Sparta posted:

And building up individual Cast entries per movie is literally no different; if he wants to pull a list of all roles Daniel Radcliffe has been in, he still has to do a search through all of Cast for name="Daniel Radcliffe" -- which would run in to the very same problem you have said occurs with my version.

Not quite. If he knows that Daniel Radcliffe acted in Harry Potter, he can find that, and use the Foreign Key associated with Harry Potter to find the others. If you ever want to attach any kind of other information to a cast or crew member (date of birth, bio), it's better to have it in one place.

# ? May 29, 2012 20:36

Sparta: Aug 14, 2003; the other white meat

Suspicious Dish posted:

The rule has been relaxed considerably, and not all productions require actors to be in the Screen Actors Guild, especially independent productions. There's also no similar rule for any of the unions of production crew members.

So make the name primary_key.

Suspicious Dish posted:

Not quite. If he knows that Daniel Radcliffe acted in Harry Potter, he can find that, and use the Foreign Key associated with Harry Potter to find the others. If you ever want to attach any kind of other information to a cast or crew member (date of birth, bio), it's better to have it in one place.

He can find the other cast of HP, but finding the roles of Daniel Radcliffe would be difficult, as it would mean cycling through every Movie->Cast->where name="Daniel Radcliffe", versus just going Cast name=DR.

Frankly, there should just be an Actor class (which is what I was sort of getting at). Have all the bio stuff in the Actor class, have a ManyToMany relationship in the Movies class referencing Actors. No need to make a separate Cast class.

# ? May 29, 2012 21:22

Maluco Marinero: Jan 18, 2001; Damn that's a
fine elephant.

Why isn't any one suggesting a custom table for the ManyToManyField relationship?

https://docs.djangoproject.com/en/dev/topics/db/models/#extra-fields-on-many-to-many-relationships

Python code:

class Cast(models.Model):
    name = models.CharField()

class Movie(models.Model):
    title = models.CharField(max_length=200)
    cast = models.ManyToManyField(Cast, through="CastRole", required=False,
				  related_name="movies")

class CastRole(models.Model):
    cast = models.ForeignKey(Cast)
    movie = models.ForeignKey(Movie)
    character_name = models.CharField()

With that, CastRole acts as an intermediate table for the ManyToMany relationship.

Python code:

actor = Cast.objects.create(name="Joe Bloggs")
movie = Movie.objects.create(title="Hero Movie")
movie2 = Movie.objects.create(title="Another Action Movie")
# to join them you need to manually create the relationship.
CastRole.objects.create(cast=actor, movie=movie, character_name="Heroic Guy")
CastRole.objects.create(cast=actor, movie=movie2, character_name="More Heroic Guy")
# from here you can retrieve the actors casting with:
all_movies = actor.movies.all()
# This won't get you the CastRoles though, son to get that you'd go:
cast_roles = CastRoles.objects.filter(cast=actor)
for cast_role in cast_roles:
    print("Played as %s in %s" % (cast_role.character_name, cast_role.movie.title))

# Outputs:
# Played as Heroic Guy in Hero Movie
# Played as More Heroic Guy in Another Action Movie

# ? May 30, 2012 00:57

German Joey: Dec 18, 2004

Every time I've ever tried to use a through table for a ManyToManyField field its ended in utter disaster. Enjoy watching your entire database implode when you try to delete one line in the through table!

# ? May 30, 2012 01:22

Maluco Marinero: Jan 18, 2001; Damn that's a
fine elephant.

I've personally had no dramas. I mean, all you're doing is just being specific, Django creates a middleman table anyway for a many to many.

# ? May 30, 2012 01:39

ufarn: May 30, 2009

M2M relations are utterly trivial. If you can't do those in Django, you should probably try writing them, until you get them right.

# ? May 30, 2012 10:51

Suspicious Dish: Sep 24, 2011; 2020 is the year of linux on the desktop, bro; Fun Shoe

ufarn posted:

M2M relations are utterly trivial. If you can't do those in Django, you should probably try writing them, until you get them right.

The problem for me is that each item you enter into an M2M needs a PK, which means it needs to be saved. That means that there's a mess of worms where I have to make sure I have all my data before I can enter it into the M2M or enter it into the database, and...

well, the code I have really now is really messy, revolving around transactions. And that doesn't work because Django's support for @commit_manually is iffy, so I have to hack around it.

# ? May 30, 2012 12:11

Maluco Marinero: Jan 18, 2001; Damn that's a
fine elephant.

The way I see it, if you are writing a reasonably complicated application you should probably do some work to abstract away all your work with the ORM. The time I spent doing this on the app I'm working with has made my view logic a breeze. Granted I had to do it if I wanted my do / undo stuff and queueing to work, but it really does simplify things for me if you break down every unit of database work into well tested methods that do the heavy lifting for you. Of course this has the plus side of down the track, making migrating away from Django's ORM to maybe SQLAlchemy somewhat less painful if it becomes necessary.

# ? May 30, 2012 12:33

Baxate: Feb 1, 2011

ufarn posted:

M2M relations are utterly trivial. If you can't do those in Django, you should probably try writing them, until you get them right.

The hard part for me is just figuring out when to use them vs a foreign key as in deciding if I have a one-to-many or a many-to-many. I don't have a DBA background, but Django is so fun to work with.

# ? May 30, 2012 16:05

ufarn: May 30, 2009

baxate posted:

The hard part for me is just figuring out when to use them vs a foreign key as in deciding if I have a one-to-many or a many-to-many. I don't have a DBA background, but Django is so fun to work with.

That's a part of the learning experience. It's not necessarily easy at first, but it's something that should and will be learnt eventually. As long as you know what you will use it for, you'll figure it out eventually.

It's been a while, since I created a new model layer, but I don't think you ever use explicit one-to-many relations in Django. So it's usually just about using a Foreign Key versus M2M.

# ? May 30, 2012 16:13

duck monster: Dec 15, 2004

Lamacq posted:

Thanks to Twitter Bootstrap, most of my web apps look like this too

I mostly build internal facing stuff for the university where I work though so nobody minds.

Hah. Yeah, my intranet sites are pretty much bootstrap bootstrap bootstrap now.

Its like a loving ron paul campagn, but with unicode crashes!

# ? May 30, 2012 17:35

deimos: Nov 30, 2006; Forget it man this bat is whack, it's got poobrain!

Suspicious Dish posted:

The problem for me is that each item you enter into an M2M needs a PK, which means it needs to be saved. That means that there's a mess of worms where I have to make sure I have all my data before I can enter it into the M2M or enter it into the database, and...

This is relational theory 101 not just django, it's proper database design. M2M is trivial once you understand proper normalization. An ORM is not an excuse to not know how relational databases work.

In order to make it easier and not have to fight the ORM the few times you may have to you can always play around with ForeignKey.on_delete and/or setting null=True.

e: null=True is not something you actually want to do if you want to maintain referential integrity, just threw it out there so that you can learn, the hard way when your entire database becomes a nightmare of potholed crap data, that referential integrity is important :toot:

deimos fucked around with this message at 22:10 on May 30, 2012

# ? May 30, 2012 22:04

Suspicious Dish: Sep 24, 2011; 2020 is the year of linux on the desktop, bro; Fun Shoe

deimos posted:

This is relational theory 101 not just django, it's proper database design. M2M is trivial once you understand proper normalization. An ORM is not an excuse to not know how relational databases work.

I want to do validation on my model before I enter it into the database. The M2M keys are also part of that validation process. That means I have to enter it into the database, add M2Ms, and then roll back the transaction if it fails validation.

Unfortunately, due to commit_manually making sure the DB is clean after committing, I get a 500 error when I return from my view because a context processor just simply ran a select query, so I have to force it clean, but that's another issue.

# ? May 30, 2012 22:25

deimos: Nov 30, 2006; Forget it man this bat is whack, it's got poobrain!

Suspicious Dish posted:

Unfortunately, due to commit_manually making sure the DB is clean after committing, I get a 500 error when I return from my view because a context processor just simply ran a select query, so I have to force it clean, but that's another issue.

Isn't this solved by changing the middleware order?
e: middleware != context processor

Err, this is your problem because you're using commit_manually as a decorator on the whole view and not taking into account querying context processors on the render call. You have two options there, abstract the transactional database manipulation into it's own method with the commit_manually decorator or use commit_manually as a context manager for the block of code that is transactional.

edit2:
another option is to simply commit/rollback after render_to_response, so this:

code:

@transaction.commit_manually
def myview(request):
    // blah
    // bleh
    transaction.commit()
    return render_to_response('blah.html')

becomes:

code:

@transaction.commit_manually
def myview(request):
    // blah
    // bleh
    transaction.commit()
    ret_val = render_to_response('blah.html')
    transaction.commit()
    return ret_val

edit3:
Yet another option is, in your context processors to do something like this:

code:

if transaction.is_managed():
    transaction.commit();

But on that one you're getting into :catdrugs:

territory.

deimos fucked around with this message at 23:22 on May 30, 2012

# ? May 30, 2012 22:44

Suspicious Dish: Sep 24, 2011; 2020 is the year of linux on the desktop, bro; Fun Shoe

I'm doing option 2, only replace the commit() with set_clean().

# ? May 31, 2012 00:01

deimos: Nov 30, 2006; Forget it man this bat is whack, it's got poobrain!

Suspicious Dish posted:

I'm doing option 2, only replace the commit() with set_clean().

Yeah, I feel it's a better approach to use one of the first 2 options (both are basically: don't use the decorator on the entire view).

# ? May 31, 2012 00:24

German Joey: Dec 18, 2004

ufarn posted:

M2M relations are utterly trivial. If you can't do those in Django, you should probably try writing them, until you get them right.

The problem has nothing to do with M2M relations, but rather is because of Django's idiotic ON DELETE CASCADE feature. Deleting a row in a through table thus causes all kinds of chaos unless you know how to explicitly step around it.

# ? May 31, 2012 00:25

deimos: Nov 30, 2006; Forget it man this bat is whack, it's got poobrain!

German Joey posted:

The problem has nothing to do with M2M relations, but rather is because of Django's idiotic ON DELETE CASCADE feature. Deleting a row in a through table thus causes all kinds of chaos unless you know how to explicitly step around it.

Hello friend, may I interest you in ForeignKey.on_delete?

# ? May 31, 2012 00:27

Jo: Jan 24, 2005; Soiled Meat

I have a complicated SQL statement which I'm not sure can be made with Django.

The simplest form I can get is:
SELECT * FROM main_pic WHERE main_pic.id IN (SELECT pic_id FROM main_tag WHERE main_tag.name='nsfw');

For extra credit, each tag has a set of votes which indicate accuracy.
SELECT * FROM main_pic WHERE main_pic.id IN (SELECT pic_id FROM main_tag WHERE (SELECT SUM(main_vote.direction) FROM main_vote AS score WHERE main_vote.target=main_tag.id) AND score > 0)

I think. :psypop:

The other is a Hamming distance question which I asked in the SQL thread, but I think can be rewritten in the select through clever use of ORDER_BY.

My question is, can I select pics from my database such that there is no 'nsfw' tag associated where the nsfw tag has more than 50% support in Django? Or do I have to use raw sql?

EDIT: Missing 'AND'.

Jo fucked around with this message at 00:35 on May 31, 2012

# ? May 31, 2012 00:33

German Joey: Dec 18, 2004

What you want is pretty trivial actually. All you need is to link your main_pic to main_tag via a Foreign Key with a related name.

code:

class main_pic(models.Model):
    ...
    tag = models.ForeignKey(main_tag, related_name='tags')
    ...

Then you can do:

code:

main_pic.objects.filter(tags__name='nsfw')

etc

https://docs.djangoproject.com/en/dev/ref/models/fields/#django.db.models.ForeignKey.related_name

You'll need to use an aggregate to do your (own) extra credit.

https://docs.djangoproject.com/en/dev/topics/db/aggregation/

As for your third question, I have no loving idea what you are asking lol. Why would an nsfw tag have support in Django? Are you asking if you can count if 50% of your pics have a nsfw tag? You can do that with an aggregate.

German Joey fucked around with this message at 00:59 on May 31, 2012

# ? May 31, 2012 00:56

Jo: Jan 24, 2005; Soiled Meat

German Joey posted:

What you want is pretty trivial actually. All you need is to link your main_pic to main_tag via a Foreign Key with a related name.
code:
class main_pic(models.Model):
    ...
    tag = models.ForeignKey(main_tag, related_name='tags')
    ...
Then you can do:
code:
main_pic.objects.filter(tags__name='nsfw')
etc

https://docs.djangoproject.com/en/dev/ref/models/fields/#django.db.models.ForeignKey.related_name

You'll need to use an aggregate to do your (own) extra credit.

https://docs.djangoproject.com/en/dev/topics/db/aggregation/

As for your third question, I have no loving idea what you are asking lol.

Thank you. That makes a lot of sense.

I wasn't clear on the Hamming Distance function, but I'll come back and worry about it later.

# ? May 31, 2012 00:59

Suspicious Dish: Sep 24, 2011; 2020 is the year of linux on the desktop, bro; Fun Shoe

That doesn't seem to be what you want, as a picture can have many tags.

Jo posted:

SELECT * FROM main_pic WHERE main_pic.id IN (SELECT pic_id FROM main_tag WHERE main_tag.name='nsfw');

That seems to be a poor man's join:

code:

SELECT * FROM main_pic, main_tag WHERE main_pic.id = main_tag.pic_id AND main_tag.name = 'nsfw';

And that can be implemented in Django like:

code:

class main_tag(models.Model):
    name = models.CharField()
    pic = models.ForeignKey(main_pic)

pictures = main_tag.objects.filter(name='nsfw').values_list('pic', flat=True)

There's probably a fancier way to do the query than values_list (maybe using the reverse relationship on a picture), but my brain is tired right now.

# ? May 31, 2012 01:44

Jo: Jan 24, 2005; Soiled Meat

Suspicious Dish posted:

That doesn't seem to be what you want, as a picture can have many tags.

That seems to be a poor man's join:
code:
SELECT * FROM main_pic, main_tag WHERE main_pic.id = main_tag.pic_id AND main_tag.name = 'nsfw';
And that can be implemented in Django like:
code:
class main_tag(models.Model):
    name = models.CharField()
    pic = models.ForeignKey(main_pic)

pictures = main_tag.objects.filter(name='nsfw').values_list('pic', flat=True)
There's probably a fancier way to do the query than values_list (maybe using the reverse relationship on a picture), but my brain is tired right now.

This is closer to the model I have, and more agreeable to my intuition about the problem. I had it just selecting the ten most recent uploads, which I think got me locked into thinking about it in terms of operating on Pic. Makes WAY more sense to select by Tags, so long as I can enforce uniqueness and order. (Should be trivial, right?)

To keep people from guessing, I'm going to dump my models below (unnecessary bits mostly excluded).

code:

class Pic(models.Model):
	img = models.ImageField(upload_to=".");
	thumb = models.ImageField(upload_to="."); # Upload both to media root.
	subject = models.CharField(max_length=200);
	text = models.TextField();
	posted = models.DateTimeField(auto_now_add=True);
	user = models.ForeignKey(User, related_name="user");
	parent = models.BigIntegerField(null=True, blank=True);

	def get_tags(self):
		return Tag.objects.filter(pic=self).order_by('-official'); # Get the tags which are official first.

	def get_replies(self):
		return Pic.objects.filter(parent=self.id);

class Tag(models.Model):
	pic = models.ForeignKey(Pic);
	name = models.CharField(max_length=200);
#Snip!

class Feature(models.Model):
	pic = models.ForeignKey(Pic);
	data = models.CharField(max_length=512);
	algorithm = models.CharField(max_length=200);

class Vote(models.Model):
	target = models.ForeignKey(Tag);
	direction = models.IntegerField()
	user = models.ForeignKey(User);

# ? May 31, 2012 05:33

Suspicious Dish: Sep 24, 2011; 2020 is the year of linux on the desktop, bro; Fun Shoe

get_tags can be replaced with related_name as well. By default, the related name is "%(class)s_set", so pic.tag_set. So to find all the pictures with 'nsfw' tags, you would do:

code:

Pic.objects.filter(tag_set__name="nsfw")

That's much better than the thing I had last time. And if you set related_name="tags", you can do:

code:

Pic.objects.filter(tags__name="nsfw")

which is probably what German Joey was trying to say.

Also, drop those semicolons, and remove the tabs. PEP8 compliance is a good thing to have.

# ? May 31, 2012 05:45

Jo: Jan 24, 2005; Soiled Meat

Thanks again for the help, everyone. Posting the solution here for anyone who stumbles on this by Google or is reading the thread.

code:

latest_pics = Pic.objects.exclude(tag__name="nsfw").exclude(img__isnull=True).exclude(img__exact='').order_by('-posted')[:desired_results];

Is effectively selecting the most recent posts which are NOT tagged NSFW.

code:

latest_pics = Pic.objects.filter(id__in=Tag.objects.annotate(score=Avg('vote__direction')).exclude(score__lt=0).exclude(name='nsfw')).exclude(img__isnull=True).exclude(img__exact='').order_by('-posted')[:desired_results];

Selects all the most recent front-page worthy images which are tagged and are safe for work. Hooray!

EDIT: Answering a question about why there are null images, replies to main posts are not required to have an image in them. This allows headless comments. I had them as separate entities at one point, but it proved actively detrimental to the feel of the site and made the handling code messy. I might reincorporate that in the future, but for now this approach works quite well.

Jo fucked around with this message at 21:47 on May 31, 2012

# ? May 31, 2012 21:11

Suspicious Dish: Sep 24, 2011; 2020 is the year of linux on the desktop, bro; Fun Shoe

Uh, why do you have NULL/blank entries in your database? You should probably just get rid of those.

Also, I'm not sure what you need to do. What's your actual question?

# ? May 31, 2012 21:22

Jo: Jan 24, 2005; Soiled Meat

Suspicious Dish posted:

Uh, why do you have NULL/blank entries in your database? You should probably just get rid of those.

Also, I'm not sure what you need to do. What's your actual question?

I'm just posting an update/thanks in case someone else stumbles across the same question. I hate finding threads where someone has the exact problem I do, only to see them reply with, "Nvm, fixed it." and nothing more.

Thanks again for your help.

# ? May 31, 2012 21:23

ufarn: May 30, 2009

Jo posted:

code:

latest_pics = Pic.objects.filter(id__in=Tag.objects.annotate(score=Avg('vote__direction')).exclude(score__lt=0).exclude(name='nsfw')).exclude(img__isnull=True).exclude(img__exact='').order_by('-posted')[:desired_results];

You can also write this as

code:

latest_pics = Pic.objects.filter(id__in=Tag.objects.annotate(score=Avg('vote__direction')).\
exclude(score__lt=0).\
exclude(name='nsfw')).\
exclude(img__isnull=True).\
exclude(img__exact='').\
order_by('-posted')[:desired_results];

It's easier to read and maintain and usually doesn't break the 80 characters per line.

# ? Jun 1, 2012 14:01

Mulozon Empuri: Jan 23, 2006

Or like so:

code:

latest_pics = Pic.objects.filter(
    id__in=Tag.objects.annotate(
        score=Avg('vote__direction')
        ).exclude(
            score__lt=0).exclude(
            name='nsfw')).exclude(
            img__isnull=True).exclude(
            img__exact='').order_by(
            '-posted'
        )[:desired_results]

Still doesn't make that a pretty query though... Wouldn't exclude(img=None) take care of '' and null?

# ? Jun 1, 2012 15:12

Suspicious Dish: Sep 24, 2011; 2020 is the year of linux on the desktop, bro; Fun Shoe

I'm quite sure you can chain multiple excludes together:

code:

exclude(score__lt=0, name='nsfw', img__isnull=True, img__exact='')

# ? Jun 1, 2012 15:36

Sharktopus: Aug 9, 2006

Suspicious Dish posted:

I'm quite sure you can chain multiple excludes together:
code:
exclude(score__lt=0, name='nsfw', img__isnull=True, img__exact='')

This would exclude only rows with ALL of those values matching, and considering the img__isnull and img__exact I suspect this means no rows will ever be excluded.

Excluding by chaining the exclude command on the queryset excludes with an OR clause

# ? Jun 1, 2012 16:19

Suspicious Dish: Sep 24, 2011; 2020 is the year of linux on the desktop, bro; Fun Shoe

Hm, I thought filter AND'd by default and exclude OR'd by default. I guess you could use a Q object, but that's getting a bit too fancy.

# ? Jun 1, 2012 17:22

how!!: Nov 19, 2011; by angerbot

Mulozon Empuri posted:

This is how I would do it:

Python code:

tags = Tag.objects.annotate(score=Avg('vote__direction')).exclude(score__lt=0).exclude(name='nsfw'))
latest_pics = (Pic.objects.filter(id__in=tags)
                          .exclude(img__isnull=True)
                          .exclude(img__exact='')
                          .order_by('-posted')[:desired_results])

# ? Jun 1, 2012 18:08

Mulozon Empuri: Jan 23, 2006

how!! posted:

This is how I would do it:

Python code:

tags = Tag.objects.annotate(score=Avg('vote__direction')).exclude(score__lt=0).exclude(name='nsfw'))
latest_pics = (Pic.objects.filter(id__in=tags)
                          .exclude(img__isnull=True)
                          .exclude(img__exact='')
                          .order_by('-posted')[:desired_results])

Ah, good thinking about the () around it all. I wonder why I never though about that.

# ? Jun 1, 2012 20:05

KingNastidon: Jun 25, 2004

Sharktopus posted:

yeah then the two model approach should work just fine.

You'll probably want to learn about aggregation on querysets: https://docs.djangoproject.com/en/dev/topics/db/aggregation/

It sounds like you'll mostly be pulling flows based on date ranges and then aggregating with the relevant metrics (min, max, mean, stddev, etc)

Thanks a bunch for your patience and help. The aggregation querysets link is going to be super helpful for what I'm looking to do.

For those of you using twitter bootstrap, are there any must-have django toolkits that make development easier, specifically forms?

# ? Jun 2, 2012 03:55

Mulozon Empuri: Jan 23, 2006

KingNastidon posted:

Thanks a bunch for your patience and help. The aggregation querysets link is going to be super helpful for what I'm looking to do.

For those of you using twitter bootstrap, are there any must-have django toolkits that make development easier, specifically forms?

I've been using https://github.com/maraujop/django-crispy-forms for my forms since forever.

# ? Jun 2, 2012 04:49

lunar detritus: May 6, 2009

Maluco Marinero posted:

Why isn't any one suggesting a custom table for the ManyToManyField relationship?

https://docs.djangoproject.com/en/dev/topics/db/models/#extra-fields-on-many-to-many-relationships

Thanks! This worked perfectly well until I realized that there are people who act and direct. I changed it to this:

Python code:

class Person(models.Model):
    name = models.CharField(max_length=255, primary_key=True)
    picture = models.URLField(blank=True) 

class Movie(models.Model):
    title = models.CharField(max_length=200)
    cast = models.ManyToManyField(Person, through="CastRole", blank=True,
                  related_name="castmovies")
    crew = models.ManyToManyField(Person, through="CrewRole", blank=True,
                  related_name="crewmovies")

class CrewRole(models.Model):
    crew = models.ForeignKey(Person)
    movie = models.ForeignKey(Movie)
    worked_as = models.CharField(max_length=255, blank=True)

class CastRole(models.Model):
    cast = models.ForeignKey(Person)
    movie = models.ForeignKey(Movie)
    character_name = models.CharField(max_length=255, blank=True)

Is this going to blow up on my face? It works (in the admin screen) but maybe I'm doing something horribly wrong that'll make my life difficult later on.

lunar detritus fucked around with this message at 05:58 on Jun 3, 2012

# ? Jun 2, 2012 21:43

Sparta: Aug 14, 2003; the other white meat

I'm working on a new, simpler project since I have realized I understand much less than I thought I did.

It's going to be a redirect-type service, but I need people to be able to add a couple different binary or choice switches; and I'd like them to be able to add a bunch.

So, the linkmodel will have a link -> how would I represent a bunch of scaleable options?

For instance, someone puts in link xyz.com and they'd like to have three switches (a= true or false, b= true or false, c= 1, 2, or 3). They are not telling me what they want these switches to be, but rather that those choices should exist.

I will then make link variations from that info which would look like:
link a:true, b:true, c:1
link a:true, b:true, c:2
link a:true, b:true, c:3
link a:true, b:false, c:1
link a:true, b:false, c:2
link a:true, b:false, c:3
link a:false, b:true, c:1
link a:false, b:true, c:2
link a:false, b:true, c:3
link a:false, b:false, c:1
link a:false, b:false, c:2
link a:false, b:false, c:3

However, I don't know what these switches are beforehand, and I don't know how many they want (probably up to 10 or 20, but I'd like to make it without a limit).

I can't figure out how I'd represent this. Any help?

# ? Jun 2, 2012 22:36

Adbot: ADBOT LOVES YOU

# ? Jun 6, 2024 09:02

Sharktopus: Aug 9, 2006

Sparta posted:

I can't figure out how I'd represent this. Any help?

Do you mean how would you represent this within python or how would you take user input for this?

# ? Jun 3, 2012 04:39

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Django Web Framework: The 'D' is silent dumbass

«‹›122 »