The Web Design & Development Megathread

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > The Web Design & Development Megathread

«‹›361 »

The Merkinman: Apr 22, 2007; I sell only quality merkins. What is a merkin you ask? Why, it's a wig for your genitals!

I have this SPA, not written in Angular/React/Anything special.
A user presses a button and content dynamically appears above the button. Depending on how much content it is, it pushes the page down, so it gives the appearance that the page has jumped (ie, the button is no longer in the persons view).
Is there any way around this?
I tried figuring out how far they were scrolled before/after the dynamic content, but as some of the content is an image, my numbers are off. I don't see how I could just hardcode the height of the image as its responsive.

# ? Dec 17, 2015 15:13

Adbot: ADBOT LOVES YOU

# ? May 16, 2024 22:07

Skandranon: Sep 6, 2008; fucking stupid, dont listen to me

The Merkinman posted:

I have this SPA, not written in Angular/React/Anything special.
A user presses a button and content dynamically appears above the button. Depending on how much content it is, it pushes the page down, so it gives the appearance that the page has jumped (ie, the button is no longer in the persons view).
Is there any way around this?
I tried figuring out how far they were scrolled before/after the dynamic content, but as some of the content is an image, my numbers are off. I don't see how I could just hardcode the height of the image as its responsive.

You could check the top property of the button in question and then change the scroll position based on that.

# ? Dec 17, 2015 15:34

Lumpy: Apr 26, 2002; La! La! La! Laaaa!; College Slice

Skandranon posted:

You could check the top property of the button in question and then change the scroll position based on that.

This. A ghetto solution is to give the button an ID, then after you insert your content, navigate to myApp.html#buttonID.

# ? Dec 17, 2015 16:09

The Merkinman: Apr 22, 2007; I sell only quality merkins. What is a merkin you ask? Why, it's a wig for your genitals!

Skandranon posted:

You could check the top property of the button in question and then change the scroll position based on that.

Isn't that just the CSS top property?

I checked how far from the top the user was right when they clicked the button...$(document).scrollTop();, and subtracted that from the whole document $( document ).height() to see how far from the bottom the user is.
Then after the content gets injected, take the new $(document).height(), subtract how far from the bottom they were, to figure out how far from the top they should be now.
Trouble is, that all calculates before the dynamic image loads, so once the image loads, the content pushes down again.

# ? Dec 17, 2015 18:08

kedo: Nov 27, 2007

Do you know the dimensions of the image before it loads? If so you can include the width and height attributes on the img tag which should solve that problem.

Or you could also maybe hide the content container until the image has loaded, and then fire your scroll event and reveal the container at the same time?

# ? Dec 17, 2015 18:28

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

Sort of a side note, where I work (sounds formal but there's only three of us) we pretty much don't let images size document flow. In nearly every case we wrap the image in a <figure> tag that has a padding bottom percentage and then position the <img> absolutely inside of that.

The significance of the padding bottom percentage is that it works as a percentage of the container width, which means it's a perfect mechanism to establish aspect ratio. Padding bottom 100% means 1:1, 50% means 2:1, etc etc. Add in a simple less/sass Mixin and you can just set the aspect ratio as you intend it, and then there's no images causing document reflow.

# ? Dec 17, 2015 18:39

Skandranon: Sep 6, 2008; fucking stupid, dont listen to me

The Merkinman posted:

Isn't that just the CSS top property?

I checked how far from the top the user was right when they clicked the button...$(document).scrollTop();, and subtracted that from the whole document $( document ).height() to see how far from the bottom the user is.
Then after the content gets injected, take the new $(document).height(), subtract how far from the bottom they were, to figure out how far from the top they should be now.
Trouble is, that all calculates before the dynamic image loads, so once the image loads, the content pushes down again.

You can either do what Lumpy suggested

Lumpy posted:

This. A ghetto solution is to give the button an ID, then after you insert your content, navigate to myApp.html#buttonID.

Or use a timeout to do the recalculation Xms after the button click happens.

# ? Dec 17, 2015 19:02

The Merkinman: Apr 22, 2007; I sell only quality merkins. What is a merkin you ask? Why, it's a wig for your genitals!

OK thanks, I just wanted to make sure I wasn't forgetting anything.
The image is responsive, so not a set pixel height. Though..going off of kedo and Maluco Marinero, it is a square, so maybe I can take its width (know since it's display:block) and use that to get the height? I'll try that.

EDIT: Oh there's the case where it only sometimes pushes down the content based on how many items there are and the resolution

. Yes I know I can figure those out too it's just that the complexity of this is larger than I thought.

Problem with Lumpy's admittedly 'ghetto' solution is that it would cause the screen to still jump to the top of whatever I have the # on.

The Merkinman fucked around with this message at 20:01 on Dec 17, 2015

# ? Dec 17, 2015 19:42

kedo: Nov 27, 2007

The Merkinman posted:

The image is responsive, so not a set pixel height. Though..going off of kedo and Maluco Marinero, it is a square, so maybe I can take its width (know since it's display:block) and use that to get the height? I'll try that.

EDIT: Oh there's the case where it only sometimes pushes down the content based on how many items there are and the resolution . Yes I know I can figure those out too it's just that the complexity of this is larger than I thought.

That sounds like the right approach to take, or if it's a square and will always be a square, you could take Maluco Marinero's exact solution and then you could measure height. The main benefit there is that you'll prevent the page height pop that happens when an image loads.

# ? Dec 17, 2015 20:06

IAmKale: Jun 7, 2007; やらないか; Fun Shoe

Alright guys, I need help with something. How am I supposed to leverage environment variables to store things like database passwords if these variables exist only for the life of the session in which they're created? Right now I run gunicorn from within Screen (soon Supervisor) to keep my server running in the background, but I can't think of a way to do this without writing a bash script to set the environment variable before launching gunicorn. That would defeat the purpose of env variables since I'd end up hardcoding the password in the bash file, right?

# ? Dec 17, 2015 23:42

Impotence: Nov 8, 2010; Lipstick Apathy

Karthe posted:

Alright guys, I need help with something. How am I supposed to leverage environment variables to store things like database passwords if these variables exist only for the life of the session in which they're created? Right now I run gunicorn from within Screen (soon Supervisor) to keep my server running in the background, but I can't think of a way to do this without writing a bash script to set the environment variable before launching gunicorn. That would defeat the purpose of env variables since I'd end up hardcoding the password in the bash file, right?

Acquire your passwords with/from something like https://github.com/square/keywhiz or https://github.com/hashicorp/vault .

# ? Dec 17, 2015 23:50

Blinkz0rz: May 27, 2001; MY CONTEMPT FOR MY OWN EMPLOYEES IS ONLY MATCHED BY MY LOVE FOR TOM BRADY'S SWEATY MAGA BALLS

At a minimum run supervisord as root or a supervisor user, set the conf files to 600 and pass the env vars in the conf file for your process.

See http://supervisord.org/configuration.html

# ? Dec 18, 2015 00:08

IAmKale: Jun 7, 2007; やらないか; Fun Shoe

Blinkz0rz posted:

At a minimum run supervisord as root or a supervisor user, set the conf files to 600 and pass the env vars in the conf file for your process.

See http://supervisord.org/configuration.html

You know what, this seems much easier to implement given my current scope of responsibility (i.e. anything programming/technical related...). And Supervisor seems to be more robust than Screen - I already had one instance of a screen session closing without notice, and I didn't know until someone told me the site stopped loading.

Now I have an ecommerce-related question. Can you guys recommend me a ecommerce package, preferably something Python-based? My boss has me bouncing from project to project so I'm trying to find something fairly turnkey that can also handle processing recurring payments for subscription publications like books or magazines. I took a look at Django-Oscar and Saleor already but Oscar had issues displaying product images and Saleor has absolutely zero documentation despite (supposedly) having a wide range of functionality built-in.

# ? Dec 22, 2015 19:28

an skeleton: Apr 23, 2012; scowls @ u

Hey guys, I've got a project where I'm transitioning from MySQL to MongoDB and there's needs for:

A) Documenting the transition and how tables are being formed into various documents/subdocuments. I.e. a row from table "Locations" is now a subdocument of a "User" document

B) A general need to document the database's schema/fields

For A, I'm really not sure what to do other than to use some UML class-ish diagrams and try and make it apparent through inheritance what came from where.

For B, I have an idea as I've seen lots of API/Schema documentation but most of it was bad. For example Confluence's schema documentation seems pretty awful. Something like Twitter's API documenation is more polished but also seemingly more geared towards building a publicly consumable API in a way that is unique to twitter, so I'm not sure where my attempt should deviate from that but it probably should in a few places.

Thanks for any help.

edit: On that note, I am looking for any advice on managing medium-sized Mongo databases. For example, this app was previously being managed by Laravel's Artisan migration system. How would/should I go about managing database migrations in MongoDB?

an skeleton fucked around with this message at 22:34 on Jan 4, 2016

# ? Jan 4, 2016 22:32

Impotence: Nov 8, 2010; Lipstick Apathy

I'm hella curious why you would move to Mongo from MySQL. I don't really have any advice on how to do it, just really really curious as to the why.

# ? Jan 5, 2016 00:26

an skeleton: Apr 23, 2012; scowls @ u

Biowarfare posted:

I'm hella curious why you would move to Mongo from MySQL. I don't really have any advice on how to do it, just really really curious as to the why.

We're moving to a team standard because boss says so. I'm technically an intern, although I've been here a while so I'm basically a regular developer, but mostly I'm just happy to have the opportunity to work with Mongo. The database structure is simple enough that it seems like it could work under a relational or non-relational DB. Anyways I'm just following orders and trying to make the transition as smooth as possible.

Notably, we're not just moving from MySQL because we hate SQL, but because the previous DB and app design/implementation of MySQL is... lackluster.

# ? Jan 5, 2016 00:43

Skandranon: Sep 6, 2008; fucking stupid, dont listen to me

an skeleton posted:

We're moving to a team standard because boss says so. I'm technically an intern, although I've been here a while so I'm basically a regular developer, but mostly I'm just happy to have the opportunity to work with Mongo. The database structure is simple enough that it seems like it could work under a relational or non-relational DB. Anyways I'm just following orders and trying to make the transition as smooth as possible.

Notably, we're not just moving from MySQL because we hate SQL, but because the previous DB and app design/implementation of MySQL is... lackluster.

But now you are documenting the hell out of your schemas... so it sounds like you really wanted an SQL DB from the beginning.

# ? Jan 5, 2016 01:43

fantastic in plastic: Jun 15, 2007; The Socialist Workers Party's newspaper proved to be a tough sell to downtown businessmen.

an skeleton posted:

Hey guys, I've got a project where I'm transitioning from MySQL to MongoDB and there's needs for:

A) Documenting the transition and how tables are being formed into various documents/subdocuments. I.e. a row from table "Locations" is now a subdocument of a "User" document

B) A general need to document the database's schema/fields

For A, I'm really not sure what to do other than to use some UML class-ish diagrams and try and make it apparent through inheritance what came from where.

For B, I have an idea as I've seen lots of API/Schema documentation but most of it was bad. For example Confluence's schema documentation seems pretty awful. Something like Twitter's API documenation is more polished but also seemingly more geared towards building a publicly consumable API in a way that is unique to twitter, so I'm not sure where my attempt should deviate from that but it probably should in a few places.

Thanks for any help.

edit: On that note, I am looking for any advice on managing medium-sized Mongo databases. For example, this app was previously being managed by Laravel's Artisan migration system. How would/should I go about managing database migrations in MongoDB?

You could try using something like Swagger or Apiary to document your API and schema.

# ? Jan 5, 2016 02:07

Blinkz0rz: May 27, 2001; MY CONTEMPT FOR MY OWN EMPLOYEES IS ONLY MATCHED BY MY LOVE FOR TOM BRADY'S SWEATY MAGA BALLS

an skeleton posted:

Hey guys, I've got a project where I'm transitioning from MySQL to MongoDB and there's needs for:

A) Documenting the transition and how tables are being formed into various documents/subdocuments. I.e. a row from table "Locations" is now a subdocument of a "User" document

B) A general need to document the database's schema/fields

For A, I'm really not sure what to do other than to use some UML class-ish diagrams and try and make it apparent through inheritance what came from where.

For B, I have an idea as I've seen lots of API/Schema documentation but most of it was bad. For example Confluence's schema documentation seems pretty awful. Something like Twitter's API documenation is more polished but also seemingly more geared towards building a publicly consumable API in a way that is unique to twitter, so I'm not sure where my attempt should deviate from that but it probably should in a few places.

Thanks for any help.

edit: On that note, I am looking for any advice on managing medium-sized Mongo databases. For example, this app was previously being managed by Laravel's Artisan migration system. How would/should I go about managing database migrations in MongoDB?

This is stupid. Your data is relational, don't convert its structure to non-relational. If you absolutely need to combine structured and unstructured data, use Postgres's json/jsonb field type.

So mainly this:

Skandranon posted:

But now you are documenting the hell out of your schemas... so it sounds like you really wanted an SQL DB from the beginning.

# ? Jan 5, 2016 05:07

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

Have a blog article (http://www.sarahmei.com/blog/2013/11/11/why-you-should-never-use-mongodb/) and a punchline if tldr

quote:

I learned something from that experience: MongoDB�s ideal use case is even narrower than our television data. The only thing it�s good at is storing arbitrary pieces of JSON. �Arbitrary,� in this context, means that you don�t care at all what�s inside that JSON. You don�t even look. There is no schema, not even an implicit schema, as there was in our TV show data. Each document is just a blob whose interior you make absolutely no assumptions about.

At RubyConf this weekend, I ran into Conrad Irwin, who suggested this use case. He�s used MongoDB to store arbitrary bits of JSON that come from customers through an API. That�s reasonable. The CAP theorem doesn�t matter when your data is meaningless. But in interesting applications, your data isn�t meaningless.

I�ve heard many people talk about dropping MongoDB in to their web application as a replacement for MySQL or PostgreSQL. There are no circumstances under which that is a good idea. Schema flexibility sounds like a great idea, but the only time it�s actually useful is when the structure of your data has no value. If you have an implicit schema � meaning, if there are things you are expecting in that JSON � then MongoDB is the wrong choice. I suggest taking a look at PostgreSQL�s hstore (now apparently faster than MongoDB anyway), and learning how to make schema changes. They really aren�t that hard, even in large tables.

If the current implementation/schema is hosed, unfuck it. Going schemaless will just bury your problems in inconsistency, not actually alleviate them.

# ? Jan 5, 2016 05:23

an skeleton: Apr 23, 2012; scowls @ u

I don't disagree with y'all, unfortunately I don't really have the clout at this point to convince the powers-that-be that we should revert back to SQL. I'm assuming that even though NoSQL dbs are technically schemaless, they still try to enforce some level of normalization? Like... we need to expect some type of structure, right? (I just read that article for the 2nd time and the answer appears to be No)

Tao Jones posted:

You could try using something like Swagger or Apiary to document your API and schema.

This is probably the ticket, I forgot about Apiary. Thanks!

# ? Jan 5, 2016 16:40

Impotence: Nov 8, 2010; Lipstick Apathy

an skeleton posted:

I don't disagree with y'all, unfortunately I don't really have the clout at this point to convince the powers-that-be that we should revert back to SQL. I'm assuming that even though NoSQL dbs are technically schemaless, they still try to enforce some level of normalization? Like... we need to expect some type of structure, right? (I just read that article for the 2nd time and the answer appears to be No)

no, not at all. lol

if you want to store documents where you can't control or know the schema associated with other relations, i think the best way is still postgres' json/jsonb type

# ? Jan 5, 2016 17:01

Lumpy: Apr 26, 2002; La! La! La! Laaaa!; College Slice

an skeleton posted:

I'm assuming that even though NoSQL dbs are technically schemaless, they still try to enforce some level of normalization? Like... we need to expect some type of structure, right?

I think you can run validators on insert, but:

Mongo's Docs posted:

Data in MongoDB has a flexible schema. Collections do not enforce document structure.

Welcome to hell.

# ? Jan 5, 2016 17:02

Dr. Arbitrary: Mar 15, 2006; Bleak Gremlin

I have to learn Drupal really quick. Any advice on how to get started?

# ? Jan 5, 2016 17:07

an skeleton: Apr 23, 2012; scowls @ u

Biowarfare posted:

no, not at all. lol

if you want to store documents where you can't control or know the schema associated with other relations, i think the best way is still postgres' json/jsonb type

Lumpy posted:

I think you can run validators on insert, but:

Welcome to hell.

Hahahaha. Well. Will report back when I'm dead.

# ? Jan 5, 2016 17:17

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

an skeleton posted:

I'm assuming that even though NoSQL dbs are technically schemaless, they still try to enforce some level of normalization? Like... we need to expect some type of structure, right? (I just read that article for the 2nd time and the answer appears to be No)

This depends on the database, but the effectively the answer will be no for the most part. You may get some degree of indexing but the whole point is the database will not enforce any constraints by default, meaning that maintenance of schematic integrity is now your application's responsibility. Any mistakes made in your application's handling of data will be happily accepted by a schemaless store, so make sure you have a high bar for code review (particularly for back end changes) as it's harder to back out of issues you've created once they're deployed.

# ? Jan 5, 2016 17:22

Impotence: Nov 8, 2010; Lipstick Apathy

an skeleton posted:

Hahahaha. Well. Will report back when I'm dead.

you are an skeleton already

# ? Jan 5, 2016 17:22

an skeleton: Apr 23, 2012; scowls @ u

Biowarfare posted:

you are an skeleton already

Tru

Maluco Marinero posted:

This depends on the database, but the effectively the answer will be no for the most part. You may get some degree of indexing but the whole point is the database will not enforce any constraints by default, meaning that maintenance of schematic integrity is now your application's responsibility. Any mistakes made in your application's handling of data will be happily accepted by a schemaless store, so make sure you have a high bar for code review (particularly for back end changes) as it's harder to back out of issues you've created once they're deployed.

I mean, I'm aware that the schema isn't enforced by the DB itself. I'm trying to document the structure of the data better for other devs and what-not. But yeah I can already tell that we'll need to watch the code we commit pretty carefully. Luckily this time around we're actually writing tests and following better practices, hopefully that will serve us well.

# ? Jan 5, 2016 18:04

Lumpy: Apr 26, 2002; La! La! La! Laaaa!; College Slice

an skeleton posted:

Tru

I mean, I'm aware that the schema isn't enforced by the DB itself. I'm trying to document the structure of the data better for other devs and what-not. But yeah I can already tell that we'll need to watch the code we commit pretty carefully. Luckily this time around we're actually writing tests and following better practices, hopefully that will serve us well.

Remember this post when the first time crunch hits and tests are the first thing thrown overboard.....

I wish you the best, and I for one would love to hear updates on this: maybe it will go well and we'll all be amazed!

# ? Jan 5, 2016 18:24

Data Graham: Dec 28, 2009; 📈📊🍪😋

The only way I've had any luck in fighting against Mongo-happy vision-type people is to explain that despite the name, Mongo isn't a database at all. It's a cache. It might as well be Redis.

You want fast key-value lookups? Great. But it isn't meant to do anything more than that.

(That article makes this point very vividly; I wish it were required reading for product managers)

# ? Jan 5, 2016 20:03

Unity Gain: Sep 15, 2007; dancing blue

Data Graham posted:

The only way I've had any luck in fighting against Mongo-happy vision-type people is to explain that despite the name, Mongo isn't a database at all. It's a cache. It might as well be Redis.

You want fast key-value lookups? Great. But it isn't meant to do anything more than that.

(That article makes this point very vividly; I wish it were required reading for product managers)

Bingo.

And without trying to start a religious war :ironicat:

I will say that I much prefer Redis.

# ? Jan 5, 2016 21:19

Analytic Engine: May 18, 2009; not the analytical engine

Does anyone have a recommendation on guides/videos/books that teach newbie web devs how to avoid slow and jerky interaction from dumb Reflow and Paint actions? The Udacity course had helpful videos.

# ? Jan 6, 2016 02:34

fuf: Sep 12, 2004; haha

I'm helping with a school's website and they have Joomla installed in the root directory and Wordpress installed in a /blog subdirectory.

I've broken the Wordpress permalinks somehow, either by restoring a backup from a few months ago (they were hacked) or by updating Joomla to the latest version.

The Wordpress home page is fine but post links are redirecting to the Joomla 404 page. Basically the requests are redirecting to /index.php instead of to /blog/index.php.

The root directory .htaccess file is the Joomla default (I'm almost certain), and the /blog directory has a Wordpress default .htaccess:

code:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>

This code should redirect /blog/my-lovely-post to /blog/index.php, right? Or do I need to change RewriteBase to /blog to account for the fact that it's in a subdirectory? :confused:

Is there something in Joomla somewhere that could be affecting this? I have zero experience with Joomla.

edit: the Joomla htaccess just for the sake of completeness:

code:

<IfModule mod_suphp.c>
  suPHP_ConfigPath /home/school/public_html/
  <Files php.ini>
    order allow,deny
    deny from all
  </Files>
</IfModule>

suPHP_ConfigPath /home/kingedwa/php.ini
## Can be commented out if causes errors, see notes above.
Options +FollowSymLinks

## Mod_rewrite in use.
RewriteEngine On

## Begin - Rewrite rules to block out some common exploits.
RewriteCond %{QUERY_STRING} base64_encode[^(]*\([^)]*\) [OR]
RewriteCond %{QUERY_STRING} (<|%3C)([^s]*s)+cript.*(>|%3E) [NC,OR]
RewriteCond %{QUERY_STRING} GLOBALS(=|\[|\%[0-9A-Z]{0,2}) [OR]
RewriteCond %{QUERY_STRING} _REQUEST(=|\[|\%[0-9A-Z]{0,2})
RewriteRule .* index.php [F]

### Begin - Joomla! core SEF Section.
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteCond %{REQUEST_URI} !^/index\.php
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule .* index.php [L]

fuf fucked around with this message at 22:36 on Jan 6, 2016

# ? Jan 6, 2016 22:32

DarkLotus: Sep 30, 2001; Lithium Hosting
Personal, Reseller & VPS Hosting
30-day no risk Free Trial &
90-days Money Back Guarantee!

Try this at the end of the joomla .htaccess file and see if it works.
You basically want to skip the joomla rules on the blog folder.

code:

### Begin - Joomla! core SEF Section.
RewriteRule ^blog(/|$) - [L,NC]
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteCond %{REQUEST_URI} !^/index\.php
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule .* index.php [L]

The - means do nothing, the L means last rule and the NC means case insensitive.

Basically you want the blog .htaccess to handle the redirects to wordpress and joomla to ignore /blog/*

# ? Jan 6, 2016 22:42

fuf: Sep 12, 2004; haha

DarkLotus posted:

Try this at the end of the joomla .htaccess file and see if it works.
You basically want to skip the joomla rules on the blog folder.
code:
### Begin - Joomla! core SEF Section.
RewriteRule ^blog(/|$) - [L,NC]
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteCond %{REQUEST_URI} !^/index\.php
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule .* index.php [L]
The - means do nothing, the L means last rule and the NC means case insensitive.

Basically you want the blog .htaccess to handle the redirects to wordpress and joomla to ignore /blog/*

Thanks man, but turns out I just needed to tweak the Wordpress htaccess properly:

code:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /blog/
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /blog/index.php [L]
</IfModule>

I'd already tried adding /blog to the RewriteBase but didn't realise I also had to add it to the RewriteRule (I thought the whole point of RewriteBase was that it went before every rule).

Anyway panic over.

# ? Jan 6, 2016 23:11

v1nce: Sep 19, 2004; Plant your brassicas in may and cover them in mulch.

Data Graham posted:

The only way I've had any luck in fighting against Mongo-happy vision-type people is to explain that despite the name, Mongo isn't a database at all. It's a cache. It might as well be Redis.

People keep pointing to that article where they go "MongoDB is a cache!", but frankly that's a dumb analogy by people who couldn't discern another type of data store, and didn't know what they wanted in the first place.

Mongo isn't a key/value store, and it certainly isn't a cache. Mongo is an unstructured document store. You can query a Mongo collections for specific k/v combo sets like {name:"joe", thing: { beans: true } }. You can't do that poo poo in Redis.
Mongo has an aggregation framework which is stupendously fast and really quite effective when it comes to aggregation. It's astoundingly faster than SQL when doing aggregates on large data sets.
Mongo doesn't give two shits about your schema. Your code needs to know how to deal with the data contained within Mongo. It's a shift in responsibilities.
Mongo has good capabilities when it comes to physically separating your database servers, but while this is a strength it is also a weakness. If your servers become disconnected they will continue to work, but some data may not be readable as it's physically not available. It's designed to allow you 100% uptime but with reliable data only 99.99% of the time, so if you need your data to be 100% all the time, you're looking in the wrong place.

Mongo also isn't as fast as Redis or Memcache for k/v data write/retrieval, especially if you physically separate your servers across long distances. If you want a cache, don't look to Mongo.
SQL on the other hand is structured and reliable. When you put data in SQL you know it'll be set in stone and all the references exist. It can be made pretty fast by actually knowing what you're doing with SQL, you can mirror the database for faster reads and reliability.
You can't query Mongo like you can query SQL either; Mongo supports cross-collection references, but joins are not a thing. You can do some complex aggregations if you're very clever, but other than that you're boned. If you want to do a join query in Mongo that involves 3 tables, you pretty much have to make 3 separate queries.

Redis is a k/v cache with persistence. Use it like one.
Mongo is best suited to fuzzy data and aggregation which is not mission critical.
SQL is a reliable database that you can do complex things in. But it's also the slowest.

There's nothing wrong with running all 3 of these things at the same time. In fact, if you had a large SQL DB you could do quite well to export it into Mongo and then run aggregation queries inside Mongo to produce reports.

Mongo's biggest failing is trying to be hip and cool and pretending it can do everything. Mongo themselves would be much better off stating its strengths and weaknesses up front, rather than letting every hipster developer discover for themselves that not only is it NoSQL it is in fact NotSQL.

# ? Jan 7, 2016 04:52

an skeleton: Apr 23, 2012; scowls @ u

v1nce posted:

People keep pointing to that article where they go "MongoDB is a cache!", but frankly that's a dumb analogy by people who couldn't discern another type of data store, and didn't know what they wanted in the first place.

Mongo isn't a key/value store, and it certainly isn't a cache. Mongo is an unstructured document store. You can query a Mongo collections for specific k/v combo sets like {name:"joe", thing: { beans: true } }. You can't do that poo poo in Redis.
Mongo has an aggregation framework which is stupendously fast and really quite effective when it comes to aggregation. It's astoundingly faster than SQL when doing aggregates on large data sets.
Mongo doesn't give two shits about your schema. Your code needs to know how to deal with the data contained within Mongo. It's a shift in responsibilities.
Mongo has good capabilities when it comes to physically separating your database servers, but while this is a strength it is also a weakness. If your servers become disconnected they will continue to work, but some data may not be readable as it's physically not available. It's designed to allow you 100% uptime but with reliable data only 99.99% of the time, so if you need your data to be 100% all the time, you're looking in the wrong place.

Mongo also isn't as fast as Redis or Memcache for k/v data write/retrieval, especially if you physically separate your servers across long distances. If you want a cache, don't look to Mongo.
SQL on the other hand is structured and reliable. When you put data in SQL you know it'll be set in stone and all the references exist. It can be made pretty fast by actually knowing what you're doing with SQL, you can mirror the database for faster reads and reliability.
You can't query Mongo like you can query SQL either; Mongo supports cross-collection references, but joins are not a thing. You can do some complex aggregations if you're very clever, but other than that you're boned. If you want to do a join query in Mongo that involves 3 tables, you pretty much have to make 3 separate queries.

Redis is a k/v cache with persistence. Use it like one.
Mongo is best suited to fuzzy data and aggregation which is not mission critical.
SQL is a reliable database that you can do complex things in. But it's also the slowest.

There's nothing wrong with running all 3 of these things at the same time. In fact, if you had a large SQL DB you could do quite well to export it into Mongo and then run aggregation queries inside Mongo to produce reports.

Mongo's biggest failing is trying to be hip and cool and pretending it can do everything. Mongo themselves would be much better off stating its strengths and weaknesses up front, rather than letting every hipster developer discover for themselves that not only is it NoSQL it is in fact NotSQL.

Thanks for this viewpoint! Our app in particular does not really do a lot of joins, which is a plus I guess. I expect there to be at least one incidence where we gently caress something up in terms of enforcing our schemas application-side, but hopefully it won't be too spectacular.

# ? Jan 7, 2016 05:02

v1nce: Sep 19, 2004; Plant your brassicas in may and cover them in mulch.

Your problem is going to be, whenever you want to do an SQL JOIN you have to instead write some custom code to do multiple Mongo queries and filter the data down to your desired results. If your code has any 5+ JOIN SQL statements, you're going to have a bad time.

If your data is structured then you should run the structured portion in SQL, end of story. Suggestions here to look at the Postgres option are probably the right answer overall, especially if your main reason for using Mongo is to deal with unstructured content.

"transitioning" from SQL to MongoDB is not a transition at all; you're changing tools. You're swapping a cross-head screwdriver for a flat-head, without realising that you won't be able to undo some types of screw any more.

# ? Jan 7, 2016 05:17

an skeleton: Apr 23, 2012; scowls @ u

I get that, and I highly doubt the data we have is 100% fully optimal for Mongo and SQL would probably work just fine. However, I also don't think our data is super complicated, we do maybe *A* join here or there, never 3 or more. So my estimate is that it will be a perfectly functional but mediocre tool for the job. However, I also have basically 0 chance of influencing a chang to MySQL at this point because my boss wants a working MEAN stack app as part of our new standard. Therefore, I will just try and build the best MEAN app that I can. I'm also early in my career and trying to grasp new technologies so it coincidentally benefits me more to use Mongo.

Will report back to let you know if this blows up in my face.

# ? Jan 7, 2016 07:11

Adbot: ADBOT LOVES YOU

# ? May 16, 2024 22:07

Skandranon: Sep 6, 2008; fucking stupid, dont listen to me

an skeleton posted:

I get that, and I highly doubt the data we have is 100% fully optimal for Mongo and SQL would probably work just fine. However, I also don't think our data is super complicated, we do maybe *A* join here or there, never 3 or more. So my estimate is that it will be a perfectly functional but mediocre tool for the job. However, I also have basically 0 chance of influencing a chang to MySQL at this point because my boss wants a working MEAN stack app as part of our new standard. Therefore, I will just try and build the best MEAN app that I can. I'm also early in my career and trying to grasp new technologies so it coincidentally benefits me more to use Mongo.

Will report back to let you know if this blows up in my face.

You know the M in MEAN can be MySQL, right?

# ? Jan 7, 2016 07:16

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > The Web Design & Development Megathread

«‹›361 »